public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <bitcoin-list@bluematt.me>
To: Jeremy Spilman <jeremy@taplink.co>,
	Gregory Maxwell <gmaxwell@gmail.com>,
	Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Date: Tue, 31 Dec 2013 13:33:54 -0800	[thread overview]
Message-ID: <4264e886-48de-40ac-921a-a60502595060@email.android.com> (raw)
In-Reply-To: <op.w8y642nryldrnw@laptop-air.hsd1.ca.comcast.net>

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

  reply	other threads:[~2013-12-31 21:34 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-08  1:17 [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts? Saïvann Carignan
2013-12-08  3:38 ` Odinn Cyberguerrilla
2013-12-08  9:03   ` Saïvann Carignan
2013-12-08 12:37     ` Luke-Jr
2013-12-08 19:16       ` Drak
2013-12-08 19:25         ` Gregory Maxwell
2013-12-08 20:28           ` Mike Hearn
2013-12-08 20:40             ` Gregory Maxwell
2013-12-08 20:51               ` Drak
2013-12-08 21:01                 ` Luke-Jr
2013-12-08 21:11                   ` Drak
2013-12-08 23:51                     ` theymos
2013-12-09  0:06                       ` Taylor Gerring
2013-12-09  6:29                       ` Jeremy Spilman
2013-12-09 10:54                       ` Roy Badami
2013-12-10  9:18                       ` Odinn Cyberguerrilla
2013-12-08 21:09                 ` Gregory Maxwell
2013-12-08 21:16             ` Saïvann Carignan
2013-12-08 21:58               ` Roy Badami
2013-12-08 23:03                 ` Mike Hearn
2013-12-09  5:32                   ` Jeff Garzik
2013-12-08 22:44               ` Gavin Andresen
2013-12-08 23:48                 ` Saïvann Carignan
2013-12-08 23:18               ` Luke-Jr
2013-12-08 23:29               ` Patrick
2013-12-08 21:46             ` Mark Friedenbach
2013-12-08 20:40           ` Drak
2013-12-08 20:50             ` Gregory Maxwell
2013-12-08 21:07               ` Drak
2013-12-08 21:14                 ` Gregory Maxwell
2013-12-08 22:27                   ` Robert McKay
2013-12-12 20:51           ` Adam Back
2013-12-31 13:39             ` Drak
2013-12-31 13:48               ` Gregory Maxwell
2013-12-31 13:59                 ` Mike Hearn
2013-12-31 14:18                   ` Gregory Maxwell
2013-12-31 14:23                     ` Mike Hearn
2013-12-31 21:25                       ` Jeremy Spilman
2013-12-31 21:33                         ` Matt Corallo [this message]
2014-01-01 10:02                           ` Jeremy Spilman
2014-01-01 11:37                             ` Wladimir
2014-01-01 15:10                         ` Mike Hearn
2014-01-01 22:15                       ` Mike Hearn
2014-01-02 19:49                   ` Jorge Timón
2013-12-31 14:05                 ` Benjamin Cordes
2014-01-03  5:45                 ` Troy Benjegerdes
2014-01-03  9:59                   ` Drak
2014-01-03 11:22                     ` Tier Nolan
2014-01-03 13:09                       ` Adam Back
2014-01-03 17:38                     ` Troy Benjegerdes
2014-01-03 18:21                       ` Jorge Timón
2014-01-04  1:43                         ` Troy Benjegerdes
2013-12-08 10:00   ` Drak
2013-12-08 12:39     ` Luke-Jr
2013-12-08 16:51     ` Gregory Maxwell
2013-12-08 16:08 ` Wladimir

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4264e886-48de-40ac-921a-a60502595060@email.android.com \
    --to=bitcoin-list@bluematt.me \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gmaxwell@gmail.com \
    --cc=jeremy@taplink.co \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox