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
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1V6zJj-0002PV-1E
for bitcoin-development@lists.sourceforge.net;
Wed, 07 Aug 2013 08:42:03 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.178 as permitted sender)
client-ip=209.85.214.178; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f178.google.com;
Received: from mail-ob0-f178.google.com ([209.85.214.178])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V6zJg-000742-49
for bitcoin-development@lists.sourceforge.net;
Wed, 07 Aug 2013 08:42:02 +0000
Received: by mail-ob0-f178.google.com with SMTP id ef5so3122078obb.23
for <bitcoin-development@lists.sourceforge.net>;
Wed, 07 Aug 2013 01:41:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.42.168 with SMTP id p8mr1607137oel.73.1375864914712; Wed,
07 Aug 2013 01:41:54 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.84.231 with HTTP; Wed, 7 Aug 2013 01:41:54 -0700 (PDT)
In-Reply-To: <4E4E5921-E8BF-4274-A062-EF1FBC331C95@grabhive.com>
References: <EE3869FD-6D83-469A-BF4F-31B79CA9950F@grabhive.com>
<51FFCA9A.6010208@gmail.com> <51FFD722.5090403@gmail.com>
<09169cb2-cc59-4261-84e9-0769ec72af6b@email.android.com>
<4E4E5921-E8BF-4274-A062-EF1FBC331C95@grabhive.com>
Date: Wed, 7 Aug 2013 10:41:54 +0200
X-Google-Sender-Auth: aLcG6EUvCLLdbFDZVF1NCi37TUE
Message-ID: <CANEZrP3bbAUhEYP3jKeBNYCZ3LU2C1DedVBQU2rYYby_Cd3QZQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Wendell <w@grabhive.com>
Content-Type: multipart/alternative; boundary=047d7b5d41a680215d04e35783ef
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1V6zJg-000742-49
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Safe auto-updating
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: Wed, 07 Aug 2013 08:42:03 -0000
--047d7b5d41a680215d04e35783ef
Content-Type: text/plain; charset=UTF-8
As you're Mac specific you could just use a modified Sparkle or something
like that. Even if you want to use a stock Sparkle, I have some code that
does threshold RSA. My intention was to use it for the Android wallet but I
never found the time. I can send you a copy if you want. But it's easier
and more robust to modify the update framework. Threshold RSA would only be
interesting if you wanted to use the Mac app store, for example.
On Wed, Aug 7, 2013 at 6:32 AM, Wendell <w@grabhive.com> wrote:
> That multisignature/blockchain commitment idea seems really solid, Peter.
>
> Thanks very much indeed everyone, this is all very helpful. Much to
> research and think about.
>
> Interestingly, a thread is presently raging on liberationtech about Tor
> Browser Bundle, and the subject of automatic updates has come up. Gregory
> Maxwell responded thusly (cross-posting for completeness):
>
> > _please_ don't deploy automatic updates in a sensitive environment
> > like this without at least quorum signatures (like gitian downloader)
> > and timed quarantine with negative signatures (harder to make strong
> > absent a jamming proof network).
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Aug 5, 2013, at 7:49 PM, Peter Todd wrote:
>
> > Gregory Maxwell had some good ideas along these lines at the san jose
> conference. Extending gitian with these kinds of features would be a good
> approach.
> >
> > But I think its worth thinking about attack models. A huge danger with
> auto-updating is that it is easy to target individuals; if I leave
> auto-updates on I am essentially trusting the developers capable of signing
> an update not to specifically try to attack me in the future, a much more
> risky thing to do than simply trusting them not to release a malicious
> release.
> >
> > Sure you can try to implement anonymous downloads and similar
> mechanisms, but they all tend to be fragile with regard to deanonymization
> attacks.
> >
> > A better way is to ensure that the act of making a release available for
> download must be public, even if you can control what binaries are made
> available to a particular target. You can do this by putting a commitment
> in the blockchain itself. Each person on the signing list creates a
> transaction with a special form from a specific pubkey that commits to the
> digest of the binaries, and the auto-update code refuses to update unless
> it sees that special transaction with a sufficient number of confirmations.
> The developers now can't make a special release for a specific target
> without letting the world know they did so, even under coercion.
> >
> > They developers could of course still make a release with code inside
> targeting a specific individual, but in theory at least the public can
> check if their builds are reproducible, and start asking questions why not?
>
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--047d7b5d41a680215d04e35783ef
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As you're Mac specific you could just use a modified S=
parkle or something like that. Even if you want to use a stock Sparkle, I h=
ave some code that does threshold RSA. My intention was to use it for the A=
ndroid wallet but I never found the time. I can send you a copy if you want=
. But it's easier and more robust to modify the update framework. Thres=
hold RSA would only be interesting if you wanted to use the Mac app store, =
for example.<div>
<br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Wed, Aug 7, 2013 at 6:32 AM, Wendell <span dir=3D"ltr"><<a href=3D=
"mailto:w@grabhive.com" target=3D"_blank">w@grabhive.com</a>></span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">That multisignature/blockchain commitment id=
ea seems really solid, Peter.<br>
<br>
Thanks very much indeed everyone, this is all very helpful. Much to researc=
h and think about.<br>
<br>
Interestingly, a thread is presently raging on liberationtech about Tor Bro=
wser Bundle, and the subject of automatic updates has come up. Gregory Maxw=
ell responded thusly (cross-posting for completeness):<br>
<br>
> _please_ don't deploy automatic updates in a sensitive environment=
<br>
> like this without at least quorum signatures (like gitian downloader)<=
br>
> and timed quarantine with negative signatures (harder to make strong<b=
r>
> absent a jamming proof network).<br>
<div class=3D"im HOEnZb"><br>
-wendell<br>
<br>
<a href=3D"http://grabhive.com" target=3D"_blank">grabhive.com</a> | <a hre=
f=3D"http://twitter.com/grabhive" target=3D"_blank">twitter.com/grabhive</a=
> | gpg: 6C0C9411<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">On Aug 5, 2013, at 7:49 PM, P=
eter Todd wrote:<br>
<br>
> Gregory Maxwell had some good ideas along these lines at the san jose =
conference. Extending gitian with these kinds of features would be a good a=
pproach.<br>
><br>
> But I think its worth thinking about attack models. A huge danger with=
auto-updating is that it is easy to target individuals; if I leave auto-up=
dates on I am essentially trusting the developers capable of signing an upd=
ate not to specifically try to attack me in the future, a much more risky t=
hing to do than simply =C2=A0trusting them not to release a malicious relea=
se.<br>
><br>
> Sure you can try to implement anonymous downloads and similar mechanis=
ms, but they all tend to be fragile with regard to deanonymization attacks.=
<br>
><br>
> A better way is to ensure that the act of making a release available f=
or download must be public, even if you can control what binaries are made =
available to a particular target. You can do this by putting a commitment i=
n the blockchain itself. Each person on the signing list creates a transact=
ion with a special form from a specific pubkey that commits to the digest o=
f the binaries, and the auto-update code refuses to update unless it sees t=
hat special transaction with a sufficient number of confirmations. The deve=
lopers now can't make a special release for a specific target without l=
etting the world know they did so, even under coercion.<br>
><br>
> They developers could of course still make a release with code inside =
targeting a specific individual, but in theory at least the public can chec=
k if their builds are reproducible, and start asking questions why not?<br>
<br>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
Get 100% visibility into Java/.NET code with AppDynamics Lite!<br>
It's a free troubleshooting tool designed for production.<br>
Get down to code-level detail for bottlenecks, with <2% overhead.<br>
Download for free and get started troubleshooting in minutes.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D48897031&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D48897031&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--047d7b5d41a680215d04e35783ef--
|
