Date: Tue, 6 Jan 2009 01:04:26 -0800 From: Tait <freebsd@t41t.com> To: freebsd-questions@freebsd.org Subject: Re: Foiling MITM attacks on source and ports trees Message-ID: <20090106090426.GS14242@ece.pdx.edu> In-Reply-To: <20090103190254.GC1253@phenom.cordula.ws> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090106090426.GS14242>