Skip site navigation (1)Skip section navigation (2)
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>