diff options
| author | Matt Corallo <bitcoin-list@bluematt.me> | 2013-12-31 13:33:54 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-12-31 21:34:28 +0000 |
| commit | 4a1d749080597af22eda5983230260a500bfb97c (patch) | |
| tree | c41927b1ea49443773435a43ebcfa1f1fc334de8 | |
| parent | ca17440d30529fbb1896abee013a6fd281ec5752 (diff) | |
| download | pi-bitcoindev-4a1d749080597af22eda5983230260a500bfb97c.tar.gz pi-bitcoindev-4a1d749080597af22eda5983230260a500bfb97c.zip | |
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
| -rw-r--r-- | fd/65efbaaad13580757873cdc11a1d5e4b250cf8 | 285 |
1 files changed, 285 insertions, 0 deletions
diff --git a/fd/65efbaaad13580757873cdc11a1d5e4b250cf8 b/fd/65efbaaad13580757873cdc11a1d5e4b250cf8 new file mode 100644 index 000000000..cc3723f01 --- /dev/null +++ b/fd/65efbaaad13580757873cdc11a1d5e4b250cf8 @@ -0,0 +1,285 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <bitcoin-list@bluematt.me>) id 1Vy6xI-00010z-Te + for bitcoin-development@lists.sourceforge.net; + Tue, 31 Dec 2013 21:34:28 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bluematt.me + designates 192.241.179.72 as permitted sender) + client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me; + helo=mail.bluematt.me; +Received: from mail.bluematt.me ([192.241.179.72]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1Vy6xH-0002aU-6X + for bitcoin-development@lists.sourceforge.net; + Tue, 31 Dec 2013 21:34:28 +0000 +Received: from [30.34.89.241] (unknown [172.56.16.62]) + by mail.bluematt.me (Postfix) with ESMTPSA id 80E13405E9; + Tue, 31 Dec 2013 21:34:20 +0000 (UTC) +User-Agent: K-9 Mail for Android +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> +MIME-Version: 1.0 +Content-Type: multipart/alternative; + boundary="----F6KKZTMEVZLMCHS889IDZWVKHSH1FI" +From: Matt Corallo <bitcoin-list@bluematt.me> +Date: Tue, 31 Dec 2013 13:33:54 -0800 +To: Jeremy Spilman <jeremy@taplink.co>, Gregory Maxwell <gmaxwell@gmail.com>, + Mike Hearn <mike@plan99.net> +Message-ID: <4264e886-48de-40ac-921a-a60502595060@email.android.com> +X-Spam-Score: -0.6 (/) +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 SPF_PASS SPF: sender matches SPF record + -0.1 RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain 1.0 HTML_MESSAGE BODY: HTML included in message +X-Headers-End: 1Vy6xH-0002aU-6X +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: Tue, 31 Dec 2013 21:34:29 -0000 + +------F6KKZTMEVZLMCHS889IDZWVKHSH1FI +Content-Type: text/plain; + charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +We already have a wonderful system for secure updating - gitian-downloade= +r. We just neither use it not bother making actual gitian releases so any= +one 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=20 +> +>infra. Anyway, my previous offer still stands. +> +>One less 'security theater' approach would be if we could provide =20 +>forward-validation of updates using the blockchain. It's always going +>to =20 +>be up to the user the first time they install the wallet to verify the=20 +> +>provenance of the binaries/source. From that point forward, we could +>make =20 +>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 +>=20 +>checking a signature on the new binaries. But it could also be more =20 +>interesting... +> +>For example, a well known address on the blockchain corresponds to =20 +>multi-sig with keys controlled by developers (or whatever key policy +>the =20 +>release team wants to impose). A spend from that address announces a +>new =20 +>release, and includes the expected hash of the file. +> +>You would probably need some way to handle the different release +>targets. =20 +>A more rigorous approach could identify all the various releases in +>terms =20 +>of a BIP32 xpubkey whose branches would correspond to the different =20 +>release trains and platform builds. Spends from a node announce the =20 +>release and the expected hash. +> +>This provides zero benefit if the wallet software is already +>compromised, =20 +>but I think this would allow trusted automatic update notification, and +>a =20 +>trusted way to deliver the expected hashes. It also might resolve some +>of =20 +>the consternation around when a release is truly "released", if that's=20 +> +>really a problem. +> +>I'm not sure how far along the slope you would want to go; 1) +>announcing =20 +>updates in the UI, 2) providing a button the user could click to verify +>a =20 +>binary matches its expected hash, 3) click to download and verify the =20 +>upgrade matches the expected hash, 4) click to upgrade +> +>Formalizing the release process around a set of privkeys (or split +>shares =20 +>of keys) may raise its own set of questions. +> +>For the download itself, I've heard the advocates of announcing =20 +>availability on the blockchain leading to a BitTorrent magnet link, but +>I =20 +>also understand objections to adding an entire BitTorrent stack into a=20 +> +>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 =20 +>> pretty hard, and saying that based on the access to the source docs +>some =20 +>> of >their MITM attacks can't beat TLS. It appears that they have the=20 +> +>> capability to do bulk MITM and rewrite of downloads as Drak says but=20 +> +>> *not* when >TLS is present, that would force more targeted attacks. +>So =20 +>> 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 =20 +>> that'd be an issue. We could consider hosting downloads on AppEngine +>or =20 +>> >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=20 +>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of +>AppDynamics Pro! +>http://pubads.g.doubleclick.net/gampad/clk?id=3D84349831&iu=3D/4140/ostg= +.clktrk +> +>------------------------------------------------------------------------ +> +>_______________________________________________ +>Bitcoin-development mailing list +>Bitcoin-development@lists.sourceforge.net +>https://lists.sourceforge.net/lists/listinfo/bitcoin-development + +------F6KKZTMEVZLMCHS889IDZWVKHSH1FI +Content-Type: text/html; + charset=utf-8 +Content-Transfer-Encoding: quoted-printable + +<!DOCTYPE HTML null ""> +<html><head><style type=3D"text/css">body { font-family:'Times New Roman'= +; font-size:13px}</style></head><body>We already have a wonderful system = +for secure updating - gitian-downloader. We just neither use it not bothe= +r making actual gitian releases so anyone can use it to verify signatures= + of downloads.<br><br><div class=3D"gmail_quote">Jeremy Spilman <jerem= +y@taplink.co> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:= + 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-le= +ft: 1ex;"> + + + +<div>I didn't know about the dedicated server meltdown, it wasn'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 could provide for= +ward-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 prove= +nance of the binaries/source. From that point forward, we could make it e= +asier if the wallet could detect updates and prove they were valid.</div>= +<div><br /></div><div>This could be as simple as hard-coding a public key= + into the client and checking a signature on the new binaries. But it cou= +ld also be more interesting...</div><div><br /></div><div>For example, a = +well known address on the blockchain corresponds to multi-sig with keys c= +ontrolled 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.</div><div><br +/></div><div>You would probably need some way to handle the different rel= +ease targets. A more rigorous approach could identify all the various rel= +eases 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 provi= +des zero benefit if the wallet software is already compromised, but I thi= +nk this would allow trusted automatic update notification, and a trusted = +way to deliver the expected hashes. It also might resolve some of the con= +sternation around when a release is truly "released", 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 but= +ton 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) c= +lick to upgrade</div><div><br +/></div><div>Formalizing the release process around a set of privkeys (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 announc= +ing availability on the blockchain leading to a BitTorrent magnet link, b= +ut I also understand objections to adding an entire BitTorrent stack into= + a wallet.</div><div><br /></div><div>On Tue, 31 Dec 2013 06:23:55 -0800,= + Mike Hearn <mike@plan99.net> wrote:<br /></div><br /><blockquote s= +tyle=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_quo= +te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= +eft:1px #ccc solid;padding-left:1ex">The site was actually moved onto a d= +edicated server 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 misse= +d this excitement :)</div><div> </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 = +clear 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 />= +</blockquote><div><br /></div><div>Well, that depends. If you watch Apple= +baums talk he is pushing TLS pretty hard, and saying that based on the ac= +cess to the source docs some of their MITM attacks can't beat TLS. It app= +ears that they have the capability to do bulk MITM and rewrite of downloa= +ds as Drak says but *not* when TLS is present, that would force more targ= +eted attacks. So to me that implies that TLS does raise the bar and is wo= +rth doing.</div> +<div><br /></div><div>However if we can't find a server that won't melt u= +nder the load, then that'd be an issue. We could consider hosting downloa= +ds on AppEngine or something else that can handle both high load and TLS.= +</div> +</div></div></div> +</blockquote><br /><br /><br /><p style=3D"margin-top: 2.5em; margin-bott= +om: 1em; border-bottom: 1px solid #000"></p><pre class=3D"k9mail"><hr /><= +br />Rapidly troubleshoot problems before they affect your business. Most= + IT <br />organizations don't have a clear picture of how application per= +formance <br />affects their revenue. With AppDynamics, you get 100% visi= +bility into your <br />Java,.NET, & PHP application. Start your 15-da= +y FREE TRIAL of AppDynamics Pro!<br /><a href=3D"http://pubads.g.doublecl= +ick.net/gampad/clk?id=3D84349831&iu=3D/4140/ostg.clktrk">http://pubad= +s.g.doubleclick.net/gampad/clk?id=3D84349831&iu=3D/4140/ostg.clktrk</= +a></pre><p style=3D"margin-top: 2.5em; margin-bottom: 1em; border-bottom:= + 1px solid #000"></p><pre class=3D"k9mail"><hr /><br />Bitcoin-developmen= +t mailing list<br />Bitcoin-development@lists.sourceforge.net<br /><a +href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development"= +>https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br = +/></pre></blockquote></div></body></html> +------F6KKZTMEVZLMCHS889IDZWVKHSH1FI-- + + |