Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

[Matt Corallo <bitcoin-list@bluematt.me>]

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

We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads.

Jeremy Spilman <jeremy@taplink.co> wrote:
>I didn't know about the dedicated server meltdown, it wasn't any of my 
>
>infra. Anyway, my previous offer still stands.
>
>One less 'security theater' approach would be if we could provide  
>forward-validation of updates using the blockchain. It's always going
>to  
>be up to the user the first time they install the wallet to verify the 
>
>provenance of the binaries/source. From that point forward, we could
>make  
>it easier if the wallet could detect updates and prove they were valid.
>
>This could be as simple as hard-coding a public key into the client and
> 
>checking a signature on the new binaries. But it could also be more  
>interesting...
>
>For example, a well known address on the blockchain corresponds to  
>multi-sig with keys controlled by developers (or whatever key policy
>the  
>release team wants to impose). A spend from that address announces a
>new  
>release, and includes the expected hash of the file.
>
>You would probably need some way to handle the different release
>targets.  
>A more rigorous approach could identify all the various releases in
>terms  
>of a BIP32 xpubkey whose branches would correspond to the different  
>release trains and platform builds. Spends from a node announce the  
>release and the expected hash.
>
>This provides zero benefit if the wallet software is already
>compromised,  
>but I think this would allow trusted automatic update notification, and
>a  
>trusted way to deliver the expected hashes. It also might resolve some
>of  
>the consternation around when a release is truly "released", if that's 
>
>really a problem.
>
>I'm not sure how far along the slope you would want to go; 1)
>announcing  
>updates in the UI, 2) providing a button the user could click to verify
>a  
>binary matches its expected hash, 3) click to download and verify the  
>upgrade matches the expected hash, 4) click to upgrade
>
>Formalizing the release process around a set of privkeys (or split
>shares  
>of keys) may raise its own set of questions.
>
>For the download itself, I've heard the advocates of announcing  
>availability on the blockchain leading to a BitTorrent magnet link, but
>I  
>also understand objections to adding an entire BitTorrent stack into a 
>
>wallet.
>
>On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn <mike@plan99.net> wrote:
>
>>> The site was actually moved onto a dedicated server temporarily and
>it
>>> melted down under the load. I wouldn't call that no progress.
>>
>> Oh, it did? When was that? I must have missed this excitement :)
>>Any idea how much load it had?
>>
>>> Perhaps I wasn't clear on the point I was making Drak's threat model
>>> is not improved in the slightest by SSL. It would be improved by
>>> increasing the use of signature checking, e.g. by making it easier.
>>
>> Well, that depends. If you watch Applebaums talk he is pushing TLS  
>> pretty hard, and saying that based on the access to the source docs
>some  
>> of >their MITM attacks can't beat TLS. It appears that they have the 
>
>> capability to do bulk MITM and rewrite of downloads as Drak says but 
>
>> *not* when >TLS is present, that would force more targeted attacks.
>So  
>> to me that implies that TLS does raise the bar and is worth doing.
>>
>> However if we can't find a server that won't melt under the load,
>then  
>> that'd be an issue. We could consider hosting downloads on AppEngine
>or  
>> >something else that can handle both high load and TLS.
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Rapidly troubleshoot problems before they affect your business. Most IT
>
>organizations don't have a clear picture of how application performance
>
>affects their revenue. With AppDynamics, you get 100% visibility into
>your 
>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of
>AppDynamics Pro!
>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&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: 5679 bytes --]