Re: [Bitcoin-development] Safe auto-updating

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 3502 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4413 bytes --]