diff options
author | Peter Todd <pete@petertodd.org> | 2013-12-19 12:44:06 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-12-19 17:44:24 +0000 |
commit | 673bdf2f7aa28611765faa160530b5b3056b0577 (patch) | |
tree | c3256c580cfc633974d0669f9a03d13400bec4f8 | |
parent | 5dd7a894bda80892be6f6ee6494386152623c65d (diff) | |
download | pi-bitcoindev-673bdf2f7aa28611765faa160530b5b3056b0577.tar.gz pi-bitcoindev-673bdf2f7aa28611765faa160530b5b3056b0577.zip |
Re: [Bitcoin-development] DarkWallet Best Practices
-rw-r--r-- | 6f/50c77e72284818a239ca11822d6fb015254986 | 172 |
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-- + + |