path: root/fd/65efbaaad13580757873cdc11a1d5e4b250cf8

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 &lt;jerem=
y@taplink.co&gt; 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 &lt;mike@plan99.net&gt; 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>&nbsp;</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, &amp; 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&amp;iu=3D/4140/ostg.clktrk">http://pubad=
s.g.doubleclick.net/gampad/clk?id=3D84349831&amp;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--