summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPeter Todd <pete@petertodd.org>2013-12-19 12:44:06 -0500
committerbitcoindev <bitcoindev@gnusha.org>2013-12-19 17:44:24 +0000
commit673bdf2f7aa28611765faa160530b5b3056b0577 (patch)
treec3256c580cfc633974d0669f9a03d13400bec4f8
parent5dd7a894bda80892be6f6ee6494386152623c65d (diff)
downloadpi-bitcoindev-673bdf2f7aa28611765faa160530b5b3056b0577.tar.gz
pi-bitcoindev-673bdf2f7aa28611765faa160530b5b3056b0577.zip
Re: [Bitcoin-development] DarkWallet Best Practices
-rw-r--r--6f/50c77e72284818a239ca11822d6fb015254986172
1 files changed, 172 insertions, 0 deletions
diff --git a/6f/50c77e72284818a239ca11822d6fb015254986 b/6f/50c77e72284818a239ca11822d6fb015254986
new file mode 100644
index 000000000..636bbe53d
--- /dev/null
+++ b/6f/50c77e72284818a239ca11822d6fb015254986
@@ -0,0 +1,172 @@
+Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
+ helo=mx.sourceforge.net)
+ by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <pete@petertodd.org>) id 1Vthe4-0007at-D3
+ for bitcoin-development@lists.sourceforge.net;
+ Thu, 19 Dec 2013 17:44:24 +0000
+Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
+ designates 62.13.148.100 as permitted sender)
+ client-ip=62.13.148.100; envelope-from=pete@petertodd.org;
+ helo=outmail148100.authsmtp.co.uk;
+Received: from outmail148100.authsmtp.co.uk ([62.13.148.100])
+ by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
+ id 1Vthe2-0003g8-EM for bitcoin-development@lists.sourceforge.net;
+ Thu, 19 Dec 2013 17:44:24 +0000
+Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
+ by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBJHiCTl045198;
+ Thu, 19 Dec 2013 17:44:12 GMT
+Received: from petertodd.org (petertodd.org [174.129.28.249])
+ (authenticated bits=128)
+ by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBJHi6Fo074940
+ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
+ Thu, 19 Dec 2013 17:44:09 GMT
+Date: Thu, 19 Dec 2013 12:44:06 -0500
+From: Peter Todd <pete@petertodd.org>
+To: Amir Taaki <genjix@riseup.net>, unsystem@lists.dyne.org,
+ bitcoin-development@lists.sourceforge.net, w@grabhive.com
+Message-ID: <20131219174406.GA12740@petertodd.org>
+References: <20131219131706.GA21179@savin>
+ <dde469d7ce77a748fb4c279334deb643.squirrel@fruiteater.riseup.net>
+ <538d3c4677a4332ae8341e37d1a77d5e.squirrel@fruiteater.riseup.net>
+MIME-Version: 1.0
+Content-Type: multipart/signed; micalg=pgp-sha256;
+ protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC"
+Content-Disposition: inline
+In-Reply-To: <538d3c4677a4332ae8341e37d1a77d5e.squirrel@fruiteater.riseup.net>
+User-Agent: Mutt/1.5.21 (2010-09-15)
+X-Server-Quench: 2a5e0d9e-68d5-11e3-b802-002590a15da7
+X-AuthReport-Spam: If SPAM / abuse - report it at:
+ http://www.authsmtp.com/abuse
+X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
+ bgdMdwsUHFAXAgsB AmUbWlNeVFl7WWo7 ag1VcwRfa1RMVxto
+ VEFWR1pVCwQmQ257 fkcYJEZycAFPfH4+ Z0NgXXUVXhV/IEYp
+ SxtJE2VSYHphaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoU
+ FhUwADk1OThDYA5Y WR1FFUgbSloKFTMn L9Ho
+X-Authentic-SMTP: 61633532353630.1023:706
+X-AuthFastPath: 0 (Was 255)
+X-AuthSMTP-Origin: 174.129.28.249/587
+X-AuthVirus-Status: No virus detected - but ensure you scan with your own
+ anti-virus system.
+X-Spam-Score: -0.2 (/)
+X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
+ See http://spamassassin.org/tag/ for more details.
+ 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
+ See
+ http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
+ for more information. [URIs: nabble.com]
+ -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
+ sender-domain
+ -0.0 SPF_PASS SPF: sender matches SPF record
+ 1.3 URI_HEX URI: URI hostname has long hexadecimal sequence
+X-Headers-End: 1Vthe2-0003g8-EM
+Subject: Re: [Bitcoin-development] DarkWallet Best Practices
+X-BeenThere: bitcoin-development@lists.sourceforge.net
+X-Mailman-Version: 2.1.9
+Precedence: list
+List-Id: <bitcoin-development.lists.sourceforge.net>
+List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
+List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
+List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
+List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
+List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
+X-List-Received-Date: Thu, 19 Dec 2013 17:44:24 -0000
+
+
+--wRRV7LY7NUeQGEoC
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+Content-Transfer-Encoding: quoted-printable
+
+On Thu, Dec 19, 2013 at 04:04:17PM -0000, Amir Taaki wrote:
+
+Looks like for this to actually go to the email lists they need to be in
+the To: field.
+
+> About signing each commit, Linus advises against it:
+>=20
+> http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html
+>=20
+> "Btw, there's a final reason, and probably the really real one. Signing
+> each commit is totally stupid. It just means that you automate it, and you
+> make the signature worth less. It also doesn't add any real value, since
+> the way the git DAG-chain of SHA1's work, you only ever need _one_
+> signature to make all the commits reachable from that one be effectively
+> covered by that one. So signing each commit is simply missing the point."
+>=20
+> What do you reckon?
+
+His point is valid, but it's valid in the context of how Linux
+development is done, not Bitcoin. The key difference being that Linus
+and other kernel developers have a model where code is passed around on
+mailing lists and between developers rather than stored on untrustworthy
+third-parties like github.
+
+For instance typically someone will submit a patch to the kernel
+development mailing list, example:
+http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg558841.html
+That patch isn't signed, and the email itself doesn't have to be PGP
+signed either. However a trusted maintainer of the relevant subsystem
+will (in theory) look over the patch carefully and commit it to their
+personal tree on a secure computer. (in theory)
+
+At some point the maintainer will create a *signed* tag on a commit with
+one or more patches, often many patches, another another maintainer
+higher in the hierarchy (maybe even Linus) will *merge* that tag into
+their tree, hopefully checking the signature first! Modern versions of
+git actually include the tag signature in the merge commit, so the
+result is signed by the original maintainer; note how this contradicts
+Linus's email with regard to the idea of separable signatures.
+Eventually multiple such groups of patches build up and the result is
+tagged as a release, and that release tag is signed.
+
+Accountability in this model rests with maintainers, and source-code
+stays on a multitude of personal, secure, locations. (in theory)
+
+
+However since we like to use github and tend to get code directly from
+it our main risk is github (or similar) being compromised. Given that I
+think we're much better off using per-commit signatures, and in effect
+continually making the statement "Yes, this commit/merge was really
+produced by me on my machine, although I may have made a mistake and
+might not have looked at the code as thoroughly as I maybe should have."
+The statement *is* weaker than Linus's model of "This signature is
+Really Official and Stuff and I've carefully checked everything." but I
+think we're much more interested in getting a strong guarantee on who
+made the commit than some strong statement about its actual contents -
+humans are fallible anyway.
+
+> Also do you approve of the other link I sent you?
+>=20
+> https://wiki.unsystem.net/index.php/DarkWallet/Negotiation
+
+I think you're conflating identities with the messaging layer; focus on
+the latter and use off-the-shelf identity systems like OpenPGP and SSL
+certificate authorities. Remember that every new identity system that
+gets involved is another way for an attacker to MITM attack you; you're
+better off using whatever the user is using already.
+
+--=20
+'peter'[:-1]@petertodd.org
+00000000000000016a442255c6d15cd6e085991c1efffc9caeff5fc6da14368a
+
+--wRRV7LY7NUeQGEoC
+Content-Type: application/pgp-signature; name="signature.asc"
+Content-Description: Digital signature
+
+-----BEGIN PGP SIGNATURE-----
+Version: GnuPG v1.4.11 (GNU/Linux)
+
+iQEcBAEBCAAGBQJSszBmAAoJEBmcgzuo5/CF9UsH/2hNZzAPnuiOvq+7gm+eURgQ
+P+6G0oU59tECxV827yW+UO1O9f56yLduUqowNgLW1V8iYih52G9hgzp79gvbPBYw
+Ndq8N3Axw12pIjBWHr+8Y0g4qOqD1yqfCN+209KL+7cxx98Voq5TOZgBuwwb6VoI
+njflMqSN91jw2ei4kcWXkZJYe7hXI+vTGPFBN0CGAGafL76t4RG6+RGPFll+X4LQ
+fci1paTjr+oj3Ukcqfl+7a8eJfctNsRKJRROAZz5ebReutDG7rWA3UeVaTxB/UHv
+osyvYeaNA1FlrLxOy+kKnHvps41XXWapEdweOZTeVRdxAYjNAMEOa83UIOclsJw=
+=LqlO
+-----END PGP SIGNATURE-----
+
+--wRRV7LY7NUeQGEoC--
+
+