diff options
| author | Mike Hearn <mike@plan99.net> | 2014-01-01 15:10:05 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-01-01 15:10:12 +0000 |
| commit | 88bbb4bef1e0760c667bfcf298d5993cc22b56e0 (patch) | |
| tree | 611344a95afbc423c5c8d2a3406cb593b64e1b5e | |
| parent | 252056468978ddc9a62f8951524fce0a4f4c60b2 (diff) | |
| download | pi-bitcoindev-88bbb4bef1e0760c667bfcf298d5993cc22b56e0.tar.gz pi-bitcoindev-88bbb4bef1e0760c667bfcf298d5993cc22b56e0.zip | |
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
| -rw-r--r-- | 2c/805b4de272bae951da4a2e5cb0433e2b1aa541 | 259 |
1 files changed, 259 insertions, 0 deletions
diff --git a/2c/805b4de272bae951da4a2e5cb0433e2b1aa541 b/2c/805b4de272bae951da4a2e5cb0433e2b1aa541 new file mode 100644 index 000000000..b46aaeb5b --- /dev/null +++ b/2c/805b4de272bae951da4a2e5cb0433e2b1aa541 @@ -0,0 +1,259 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1VyNQy-0005AA-32 + for bitcoin-development@lists.sourceforge.net; + Wed, 01 Jan 2014 15:10:12 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.214.180 as permitted sender) + client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com; + helo=mail-ob0-f180.google.com; +Received: from mail-ob0-f180.google.com ([209.85.214.180]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1VyNQw-0007St-S4 + for bitcoin-development@lists.sourceforge.net; + Wed, 01 Jan 2014 15:10:12 +0000 +Received: by mail-ob0-f180.google.com with SMTP id wo20so13384309obc.25 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 01 Jan 2014 07:10:05 -0800 (PST) +MIME-Version: 1.0 +X-Received: by 10.182.213.166 with SMTP id nt6mr10055541obc.53.1388589005372; + Wed, 01 Jan 2014 07:10:05 -0800 (PST) +Sender: mh.in.england@gmail.com +Received: by 10.76.95.200 with HTTP; Wed, 1 Jan 2014 07:10:05 -0800 (PST) +In-Reply-To: <op.w8y642nryldrnw@laptop-air.hsd1.ca.comcast.net> +References: <52A3C8A5.7010606@gmail.com> + <1795f3067ba3fcdd0caf978cc59ff024.squirrel@fruiteater.riseup.net> + <52A435EA.7090405@gmail.com> <201312081237.24473.luke@dashjr.org> + <CANAnSg2OrmQAcZ+cZdtQeADicH3U29QOgYPfP1AQhOMP6+P1wg@mail.gmail.com> + <CAAS2fgR0khyJxmz9c2Oc87hOFgiNuiPJuaeugGajdo_EcKEW9w@mail.gmail.com> + <20131212205106.GA4572@netbook.cypherspace.org> + <CANAnSg3nPhrk2k=yDKf39AuBQnSuTWJbgANdMhGe=soiOy0NTw@mail.gmail.com> + <CAAS2fgTmWRMxYweu3sNn_X7grgjUqTQujM-DbZRxG_YMZnD=7g@mail.gmail.com> + <CANEZrP2X_63qkuNuk0MvsLR9ewd7HR0mPVaD7bZSgWMTJ5-9FQ@mail.gmail.com> + <CAAS2fgQmMZ6RYjbJ6ZfFO5+ZhZoR4d4yMf8CXLXKPmZt3-Je4Q@mail.gmail.com> + <CANEZrP1mdJNa7ADkUXTGDNKMSCROjGAVbMXZXxodxCz1LFDzZw@mail.gmail.com> + <op.w8y642nryldrnw@laptop-air.hsd1.ca.comcast.net> +Date: Wed, 1 Jan 2014 15:10:05 +0000 +X-Google-Sender-Auth: JsIT5RuE5cLuJY2NbiUqmu1pEeQ +Message-ID: <CANEZrP3DmATBpi_SNS2R98R2Lf3cfuYK3dE_6yCwTL-MgYpHLg@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Jeremy Spilman <jeremy@taplink.co> +Content-Type: multipart/alternative; boundary=001a11c2e60a6782a804eeea129b +X-Spam-Score: -0.5 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1VyNQw-0007St-S4 +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Dedicated server for bitcoin.org, + your thoughts? +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 01 Jan 2014 15:10:12 -0000 + +--001a11c2e60a6782a804eeea129b +Content-Type: text/plain; charset=UTF-8 + +That seems overly complicated, there's no need for the Bitcoin protocol to +be involved. Deterministic builds with threshold signed updates are a +problem the entire crypto community is now interested in solving - any +solution should be generic. + +Really all you need is an update engine that allows a CHECKMULTISIG type +approach. When the update engine is not under our control, i.e. on Android, +Shoup style RSA threshold signatures can potentially work (though I must +admit, I have never found time to play with the implementation I have for +that algorithm). + + + +On Tue, Dec 31, 2013 at 9:25 PM, 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. +> +> +> +> +> + +--001a11c2e60a6782a804eeea129b +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">That seems overly complicated, there's no need for the= + Bitcoin protocol to be involved. Deterministic builds with threshold signe= +d updates are a problem the entire crypto community is now interested in so= +lving - any solution should be generic.<div> +<br></div><div>Really all you need is an update engine that allows a CHECKM= +ULTISIG type approach. When the update engine is not under our control, i.e= +. on Android, Shoup style RSA threshold signatures can potentially work (th= +ough I must admit, I have never found time to play with the implementation = +I have for that algorithm).</div> +<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail= +_quote">On Tue, Dec 31, 2013 at 9:25 PM, Jeremy Spilman <span dir=3D"ltr">&= +lt;<a href=3D"mailto:jeremy@taplink.co" target=3D"_blank">jeremy@taplink.co= +</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><u></u> + + +<div><div>I didn't know about the dedicated server meltdown, it wasn= +9;t any of my infra. Anyway, my previous offer still stands.</div><div><br>= +</div><div>One less 'security theater' approach would be if we coul= +d provide forward-validation of updates using the blockchain. It's alwa= +ys going to be up to the user the first time they install the wallet to ver= +ify the provenance of the binaries/source. From that point forward, we coul= +d make it easier if the wallet could detect updates and prove they were val= +id.</div> +<div><br></div><div>This could be as simple as hard-coding a public key int= +o the client and checking a signature on the new binaries. But it could als= +o be more interesting...</div><div><br></div><div>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 sp= +end from that address announces a new release, and includes the expected ha= +sh of the file.</div> +<div><br></div><div>You would probably need some way to handle the differen= +t 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.</div> +<div><br></div><div>This provides zero benefit if the wallet software is al= +ready compromised, but I think this would allow trusted automatic update no= +tification, and a trusted way to deliver the expected hashes. It also might= + resolve some of the consternation around when a release is truly "rel= +eased", if that's really a problem.</div> +<div><br></div><div>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 cou= +ld 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</div= +> +<div><br></div><div>Formalizing the release process around a set of privkey= +s (or split shares of keys) may raise its own set of questions.</div><div><= +br></div><div>For the download itself, I've heard the advocates of anno= +uncing availability on the blockchain leading to a BitTorrent magnet link, = +but I also understand objections to adding an entire BitTorrent stack into = +a wallet.</div> +<div><div class=3D"h5"><div><br></div><div>On Tue, 31 Dec 2013 06:23:55 -08= +00, Mike Hearn <<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mik= +e@plan99.net</a>> wrote:<br></div><br><blockquote style=3D"margin:0 0 0.= +80ex;border-left:#0000ff 2px solid;padding-left:1ex"> +<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo= +ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c= +cc solid;padding-left:1ex">The site was actually moved onto a dedicated ser= +ver temporarily and it<br> + + +melted down under the load. I wouldn't call that no progress.<br></bloc= +kquote><div><br></div><div>Oh, it did? When was that? I must have missed th= +is excitement :)</div><div>=C2=A0</div><div>Any idea how much load it had?<= +br> + +</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = +0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Perhaps I wasn't cl= +ear on the point I was making Drak's threat model<br> +is not improved in the slightest by SSL. It would be improved by<br> +increasing the use of signature checking, e.g. by making it easier.<br></bl= +ockquote><div><br></div><div>Well, that depends. If you watch Applebaums ta= +lk he is pushing TLS pretty hard, and saying that based on the access to th= +e source docs some of their MITM attacks can't beat TLS. It appears tha= +t 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.</di= +v> + +<div><br></div><div>However if we can't find a server that won't me= +lt under the load, then that'd be an issue. We could consider hosting d= +ownloads on AppEngine or something else that can handle both high load and = +TLS.</div> + +</div></div></div> +</blockquote><br><br><br></div></div></div></blockquote></div><br></div> + +--001a11c2e60a6782a804eeea129b-- + + |