1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
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--
|
