From owner-freebsd-questions@FreeBSD.ORG Tue Jan 6 09:04:30 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70B351065700 for ; Tue, 6 Jan 2009 09:04:30 +0000 (UTC) (envelope-from freebsd@t41t.com) Received: from ehlo.cat.pdx.edu (unknown [IPv6:2610:10:20:208:2e0:81ff:fe5d:b35f]) by mx1.freebsd.org (Postfix) with ESMTP id 333C28FC16 for ; Tue, 6 Jan 2009 09:04:30 +0000 (UTC) (envelope-from freebsd@t41t.com) Received: from nemo.ece.pdx.edu (root@nemo.ece.pdx.edu [131.252.209.162]) by ehlo.cat.pdx.edu (8.14.2/8.14.2/Debian-2build1) with ESMTP id n0694RVl027321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Jan 2009 01:04:27 -0800 Received: from nemo.ece.pdx.edu (tait@localhost [127.0.0.1]) by nemo.ece.pdx.edu (8.13.6/8.13.1) with ESMTP id n0694Rqx004008 for ; Tue, 6 Jan 2009 01:04:27 -0800 (PST) Received: (from tait@localhost) by nemo.ece.pdx.edu (8.13.6/8.12.6/Submit) id n0694QcS004007 for freebsd-questions@freebsd.org; Tue, 6 Jan 2009 01:04:26 -0800 (PST) X-Authentication-Warning: nemo.ece.pdx.edu: tait set sender to freebsd@t41t.com using -f Date: Tue, 6 Jan 2009 01:04:26 -0800 From: Tait To: freebsd-questions@freebsd.org Message-ID: <20090106090426.GS14242@ece.pdx.edu> References: <20090102164412.GA1258@phenom.cordula.ws> <495E4F24.80209@unsane.co.uk> <20090103013825.18910bf5@gumby.homeunix.com> <495F5DD7.2070302@infracaninophile.co.uk> <20090103190254.GC1253@phenom.cordula.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090103190254.GC1253@phenom.cordula.ws> User-Agent: Mutt/1.5.7i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ehlo.cat.pdx.edu [131.252.208.106]); Tue, 06 Jan 2009 01:04:27 -0800 (PST) X-Spam-Status: No, score=0.0 required=6.0 tests=none autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ehlo.cat.pdx.edu X-Virus-Scanned: ClamAV 0.92.1/8838/Mon Jan 5 17:46:11 2009 on ehlo.cat.pdx.edu X-Virus-Status: Clean Subject: Re: Foiling MITM attacks on source and ports trees X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 09:04:30 -0000 > > Unless designed carefully, there will be substantial logistical > > problems to maintaining such lists of signatures. > ... > > You can then verify the correctness of what's on your disk ... > > The idea is that one needs to get this public key only once > ... > IMHO, this could or should take place at the subversion server itself. This problem has already been solved in the form of Git*. Now whether FreeBSD can/will migrate to Git or an equivalent for version control is another question. The security benefits would result even if a trusted person (the FreeBSD security team, maybe?) maintained a git mirror of the CVS/Subversion/Whatever repository. Git avoids the issue of versioned lists of signatures by simply making the version history of the repository an unbroken chain. If any link in history is changed, the sha1 checksums no longer compute. By simply verifying a sha1 hash, you can be assured (at least, as assured as [that implementation of] sha1 can make you feel) that the files at that point in time and all their prior history are exactly the same on your computer as what's on the distribution server. No lengthy lists or checksum tuples are required. The checksums are "built in" to the version control itself. Git also provides a mechanism for cryptographic sign-off of tags, which would provide the public/private keyed infrastructure you're trying to (awkwardly) replicate with SSL and PKI. The combination of sha1-strength history integrity verification and cryptographic tags mean all the information necessary to validate your on-disk source tree (and its history) is widely available and easily verified even if obtained from an untrusted source. You will need a secure means of obtaining either a (single) sha1 hash or a public key, but everything else can e verified once you have that small bit of very public (and therefore difficult to forge) information. Even if Git isn't the answer, it's at least worth stealing some of their ideas. * http://git.or.cz