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 --]
next prev parent 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 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$(echo .)me \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
--cc=jeremy@taplink$(echo .)co \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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