From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: <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: From: Mike Hearn To: Wendell 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 Subject: Re: [Bitcoin-development] Safe auto-updating X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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.



On Wed, Aug 7, 2013 at 6:32 AM, Wendell <w@grabhive.com> wro= te:
That multisignature/blockchain commitment id= ea seems really solid, Peter.

Thanks very much indeed everyone, this is all very helpful. Much to researc= h and think about.

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):

> _please_ don't deploy automatic updates in a sensitive environment=
> like this without at least quorum signatures (like gitian downloader)<= br> > 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, P= eter 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 a= pproach.
>
> 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.
>
> Sure you can try to implement anonymous downloads and similar mechanis= ms, 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 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.
>
> 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?


-----------------------------------------------------------= -------------------
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/gam= pad/clk?id=3D48897031&iu=3D/4140/ostg.clktrk
___________________= ____________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--047d7b5d41a680215d04e35783ef--