Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Vz4VD-0006L5-3J for bitcoin-development@lists.sourceforge.net; Fri, 03 Jan 2014 13:09:27 +0000 X-ACL-Warn: Received: from mout.perfora.net ([74.208.4.195]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Vz4VB-0002bY-Gk for bitcoin-development@lists.sourceforge.net; Fri, 03 Jan 2014 13:09:27 +0000 Received: from netbook (88-105-1-32.dynamic.dsl.as9105.com [88.105.1.32]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LbMqQ-1Va9rc20JW-00kmfq; Fri, 03 Jan 2014 08:09:18 -0500 Received: by netbook (Postfix, from userid 1000) id EB6042E4A57; Fri, 3 Jan 2014 14:09:12 +0100 (CET) Received: by flare (hashcash-sendmail, from uid 1000); Fri, 3 Jan 2014 14:09:12 +0100 Date: Fri, 3 Jan 2014 14:09:11 +0100 From: Adam Back To: Tier Nolan Message-ID: <20140103130911.GA12653@netbook.cypherspace.org> References: <52A435EA.7090405@gmail.com> <201312081237.24473.luke@dashjr.org> <20131212205106.GA4572@netbook.cypherspace.org> <20140103054515.GL3180@nl.grid.coop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:140103:tier.nolan@gmail.com::jfFiKEX44yNICJm4:00000000000000000 0000000000000000000000001zsO X-Hashcash: 1:20:140103:bitcoin-development@lists.sourceforge.net::XhYu64mu5o+KC ttz:0000000000000000000008rp X-Hashcash: 1:20:140103:adam@cypherspace.org::55nwJyH+pyUmxaWJ:00000000000000000 0000000000000000000000003QDE X-Provags-ID: V02:K0:pVTi5kv6sorXXrbWS+Q099UBQR4q8VZf7bDLU16fACS xfCcV4ZtcWG135JxEPdA4OQg/+nw/TMWzKDSmneLVkQdGAjNjD qMqj1Jux5mwn0qPB3EAnTdA8aKQ/gbt5SNH5TNZkzcmZGrP6LF Yhoz1lEwQDc3vjch/9dQmvnq+I4845nNqNGcmN0Ede7En/YEqD 3Ass4NFou+ajeBTH67rbK4q7fd9qMx3NQrEy25SD6ahLZ6PelB 0rBCFpILt09Pm4bP9IPIR+FZwI64xtj5c3UC69nKRv3jCFTZOy JiA7Ykh6jrTqNr+oRxEwNa69qjnHeKsptJ3TCs8GV9y9Nwe72P 4033bkrpjwO6MLN4S/IwOPJ9B3lFDRHjuGIYIZjCH X-Spam-Score: -0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [74.208.4.195 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record X-Headers-End: 1Vz4VB-0002bY-Gk Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jan 2014 13:09:27 -0000 You know if you want to make some form of investment, you might like make an attempt to look them up on the internet, check the phone number in a phone book or directory enquiries, look for references and reviews? So it is with the hash of the binary you are about to trust with your investment funds. I dont think its such a difficult question. Ask your more technical friends to confirm this hash is correct. Its interesting that hashes are more trustworthy than signatures, since all the NSLs and backdoors, its hard to trust a signature. I have the same problem with linux distros that want to install hundreds of components downloaded over the internet, based on signatures. I would far rather a merkle hash of the distribution at that point in time, which authenticates directly any of the optional downloadable components. (Or better yet a distro that like comes on a CD and doesnt download anything... Amazing how most CD and even DVD iso images immediately download stupid things like fonts??? What were they thinking? I downloaded fedora > 4GB of stuff and they need to download a font just to get past step 2 of the installer? Thats a sensless, retrograde, selective backdoor opportunity.) Adam On Fri, Jan 03, 2014 at 11:22:35AM +0000, Tier Nolan wrote: > On Fri, Jan 3, 2014 at 9:59 AM, Drak <[1]drak@zikula.org> wrote: > > Which is why, as pointed out several times at 30c3 by several renowned > figures, why cryptography has remained squarely outside of mainstream > use. It needs to just work and until you can trust the connection and > what the end point sends you, automatically, it's a big fail and the > attack vectors are many. > I can just see my mother or grandma manually checking the hash > of a download... > > Maybe a simple compromise would be to add a secure downloader to the > bitcoin client. > The download link could point to a meta-data file that has info on the > download. > file_url= > hash_url= > sig_url= > message=This is version x.y.z of the bitcoin client > It still suffers from the root CA problem though. The bitcoin client > would accept Gavin's signature or a "core team" signature. > At least it would provide forward security. > It could also be used to download files for different projects, with > explicit warnings that you are adding a new trusted key. > When you try to download, you would be given a window > Project: Some Alternative Wallet > Signed by: P. Lead > Message: > Confirm download Yes No > However, even if you do that, each trusted key is only linked to a > particular project. > It would say if the project and/or leader is unknown. > >References > > 1. mailto:drak@zikula.org >------------------------------------------------------------------------------ >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@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development