From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V6Ouq-0002jo-Gv for bitcoin-development@lists.sourceforge.net; Mon, 05 Aug 2013 17:49:56 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.110 as permitted sender) client-ip=62.13.148.110; envelope-from=pete@petertodd.org; helo=outmail148110.authsmtp.com; Received: from outmail148110.authsmtp.com ([62.13.148.110]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V6Ouo-0001L0-GS for bitcoin-development@lists.sourceforge.net; Mon, 05 Aug 2013 17:49:56 +0000 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt7.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r75HnkP1037388; Mon, 5 Aug 2013 18:49:46 +0100 (BST) Received: from [25.13.141.185] ([24.114.68.193]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r75Hnfl8023210; Mon, 5 Aug 2013 18:49:42 +0100 (BST) User-Agent: K-9 Mail for Android In-Reply-To: <51FFD722.5090403@gmail.com> References: <51FFCA9A.6010208@gmail.com> <51FFD722.5090403@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Peter Todd Date: Mon, 05 Aug 2013 13:49:36 -0400 To: Alan Reiner , bitcoin-development@lists.sourceforge.net Message-ID: <09169cb2-cc59-4261-84e9-0769ec72af6b@email.android.com> X-Server-Quench: 6907546a-fdf7-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdgcUGUATAgsB AmUbWlxeVFR7XWA7 aQ5PbARZfExGQQRj U1dMSlVNFEsqBhl5 WEhCWhlwdAdHeDBx Zk9hWj5dVUR9cEJ7 E1MCQTsBeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4wFzAx DxkfATJqAFUJTjky KRNO X-Authentic-SMTP: 61633532353630.1019:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.68.193/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1V6Ouo-0001L0-GS Subject: Re: [Bitcoin-development] Safe auto-updating X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 17:49:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Gregory Maxwell had some good ideas along these lines at the san jose conference. Extending gitian with these kinds of features would be a good approach. But I think its worth thinking about attack models. A huge danger with auto-updating is that it is easy to target individuals; if I leave auto-updates on I am essentially trusting the developers capable of signing an update not to specifically try to attack me in the future, a much more risky thing to do than simply trusting them not to release a malicious release. Sure you can try to implement anonymous downloads and similar mechanisms, but they all tend to be fragile with regard to deanonymization attacks. A better way is to ensure that the act of making a release available for download must be public, even if you can control what binaries are made available to a particular target. You can do this by putting a commitment in the blockchain itself. Each person on the signing list creates a transaction with a special form from a specific pubkey that commits to the digest of the binaries, and the auto-update code refuses to update unless it sees that special transaction with a sufficient number of confirmations. The developers now can't make a special release for a specific target without letting the world know they did so, even under coercion. They developers could of course still make a release with code inside targeting a specific individual, but in theory at least the public can check if their builds are reproducible, and start asking questions why not? Alan Reiner wrote: >Indeed. You can hardcode a "distributor" public key in the software, >and client software will only trust signed data from that key. Of >course, the private key for that data is not kept on the server >distributing the signed checksums. Ideally it would be kept offline, >and the couple-times-per-year that you actually execute an upgrade, you >sign the new checksums offline and upload the signed checksum to the >distribution server. Then even if the server is compromised, the >client-side software will not accept a bogus checksum because it won't >bear the right signature. > >If you do this, it would be good to also have some kind of revocation >process that can be used in the event of the offline key being >compromised. You won't be able to "switch" keys, as that would defeat >the purpose (the attacker who compromises the offline key could just >issue a replacement with his own). Instead, it would be an >irreversible >broadcast that would force clients to start rejecting updates from that >key. If the key is compromised (and find out), you broadcast the >revocation and the users will stop auto-updating, and be given a >warning >that they should manually upgrade the software through trusted >channels. It's not failproof, but it's a decent way to minimize damage >if you discover compromise early enough. > >-Alan > > > > > > >On 08/05/2013 11:54 AM, Daniel F wrote: >> If you want package authentication, you should at least throw in some >> digital signing, not just a checksum. With a compromised host, both >the >> checksum and binaries can be changed undetectably, but if there's a >> signature made by a key that is not kept on the host, there's no way >to >> fake a valid binary. >> >> There may be other issues people would want to bring up, but surely >just >> a checksum is not sufficient. >> >> on 08/05/2013 10:39 AM Wendell said the following: >>> For usability purposes, we at Hive would like to have an >>> auto-updater >> in our wallet app. >>> What is a safe way to do this? I understand that Bitcoin-QT lacks >>> such >> an updater for security reasons... Has been thought out in more >detail >> since that decision was made? >>> We have been toying around with the idea of placing one server >>> behind >> a Tor hidden service, whose only function is to output a checksum of >the >> update package. The theory is that if it is well-secured, it will at >> least be immune to tampering at the physical hosting level. >>> Any thoughts or advice about any of this? >>> -wendell >>> >>> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411 >>> >>> >>> >>> >------------------------------------------------------------------------------ >>> Get your SQL database under version control now! >>> Version control is standard for application code, but databases >havent >>> caught up. So what steps can you take to put your SQL databases >under >>> version control? Why should you start doing it? Read more to find >out. >>> >http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk >>> >>> >>> >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >> >> >------------------------------------------------------------------------------ >> Get your SQL database under version control now! >> Version control is standard for application code, but databases >havent >> caught up. So what steps can you take to put your SQL databases under > >> version control? Why should you start doing it? Read more to find >out. >> >http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >------------------------------------------------------------------------------ >Get your SQL database under version control now! >Version control is standard for application code, but databases havent >caught up. So what steps can you take to put your SQL databases under >version control? Why should you start doing it? Read more to find out. >http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iHkEAREIADkFAlH/5a8yHFBldGVyIFRvZGQgKGxvdyBzZWN1cml0eSBrZXkpIDxw ZXRlQHBldGVydG9kZC5jYT4ACgkQpEFN739thozkAACeIu7GINlJqPObyZ+87vA+ 2hMphHYAoI3CyuGuSr7xYm0pus0DVgnQc/vD =nVJA -----END PGP SIGNATURE-----