Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V6OMD-0005C8-Jw for bitcoin-development@lists.sourceforge.net; Mon, 05 Aug 2013 17:14:09 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of fastmail.co.uk designates 66.111.4.25 as permitted sender) client-ip=66.111.4.25; envelope-from=jim618@fastmail.co.uk; helo=out1-smtp.messagingengine.com; Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1V6OMC-0007aB-Al for bitcoin-development@lists.sourceforge.net; Mon, 05 Aug 2013 17:14:09 +0000 Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 8F7BC21674 for ; Mon, 5 Aug 2013 13:14:00 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute1.internal (MEProxy); Mon, 05 Aug 2013 13:14:01 -0400 Received: by web5.nyi.mail.srv.osa (Postfix, from userid 99) id 902EAE00BB0; Mon, 5 Aug 2013 13:14:00 -0400 (EDT) Message-Id: <1375722840.32601.6177639.39D38240@webmail.messagingengine.com> X-Sasl-Enc: IYEQbtIZ7u7MQfDpt9d6OCNrvmxDdDPZgVr1Zd4/ia3i 1375722840 From: Jim To: bitcoin-development@lists.sourceforge.net MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-2d520484 Date: Mon, 05 Aug 2013 18:14:00 +0100 In-Reply-To: <51FFD722.5090403@gmail.com> References: <51FFCA9A.6010208@gmail.com> <51FFD722.5090403@gmail.com> X-Spam-Score: -1.4 (-) 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 (jim618[at]fastmail.co.uk) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (jim618[at]fastmail.co.uk) -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1V6OMC-0007aB-Al 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:14:09 -0000 One approach you could use would be to use bitcoin signing on a list of the build artifacts together with their SHA256 hashes. If you have a look at the MultiBit release notes you get the overall idea: https://multibit.org/releases/multibit-0.5.13/release.txt Currently these aren't machine readable but you can imagine having a machine readable statement with: + a list of the files in the build + their SHA256 hashes + the above bitcoin signed by multiple signatures e.g. 2 of 3 The client can then download the file, check the signature, check the hashes and knows which files to download. The acceptable Bitcoin addresses for signatures would be a whitelist in the client code. On Mon, Aug 5, 2013, at 05:47 PM, 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 -- https://multibit.org Money, reinvented