Reflections on Trusting Trust

[Robert Watson]

On Thu, 1 Dec 2005, Peter Jeremy wrote:

>> But this assumes the signer trusts the FreeBSD.org security:
>
> If you don't trust the FreeBSD Project you wouldn't run FreeBSD.
>
>> Without ssh access there's no way to insert a key into the CVS 
>> repository.
>
> Assuming no security holes in the infrastructure...  How can I tell that 
> my private copy of the FreeBSD Project's CVS repository is the same as 
> the one on whatever.FreeBSD.org?

I think this is actually the real core of the issue: what we want is 
improved confidence of safe delivery in the presence of limited attackers 
on the wire.  That is, we would like to be able to tell the user that, 
yes, if they managed to get a first FreeBSD ISO in some uncorrupted form 
(from a trusted vendor, or even from an initially insecure download, which 
is what 99% will be), from then on they will get source updates generated 
using keying material that matches something on that ISO, only packages 
that generated using keying material that matches something on that ISO, 
etc.  I agree with the basic concept that, despite the infrastructural 
complexities and desire to avoid promising more than we can really 
provide, that there are incremental transport and packaging improvements 
we can make that will provide for safer delivery of our parts to the user.

Whether it's using portsnap's signature mechanism, signatures on packages, 
an https download option for pulling down updates, SSL wrappings for 
cvsup, or whatever, it seems like we can do better.  If we do go down the 
route of things like https, X509, and all that I think we should be very 
careful to distinguish the CERT chain and roots used for our own purposes, 
and for normal SSL use, such that if our update chain or package chain is 
compromised, it doesn't mean a FreeBSD user is immediately vulnerable to 
more general SSL attacks against other entities (ie., www.mybank.com).

Robert N M Watson