Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2013-12-31 📝 Original message:We already have a ...
📅 Original date posted:2013-12-31
📝 Original message: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 at 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 at 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 at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131231/eaa34c28/attachment.html>;
📝 Original message: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 at 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 at 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 at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131231/eaa34c28/attachment.html>;