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