Secure updating of OS and ports

[Charles Swiger]

On Nov 17, 2003, at 9:19 AM, Jarkko Santala wrote:
[ ... ]
> While that would work great for ports, the actual source tree could be 
> a
> problem. If all files would have associated md5sums which would all be
> checked during compilation, it might make the whole process unbearably
> slow on slow machines. Although then there might be a switch to disable
> the checking to increase speed at the cost of security.

Using md5 checksums on distfiles has proven useful in the case where a 
source tarball has been trojaned.  But a tarball is a self-contained 
entity which can be verified as a whole-- you don't have to verify each 
file within that archive if you trust the message digest algorithm 
being used.  And if you trust the people who created the original 
tarball, of course.

> Also there's the problem of locating the entity that would check all 
> the
> source code both in src and ports before signing.  Of course the ports
> could be signed by maintainers using a method provided by the FreeBSD
> project, such as a key associated with a certificate.

To some extent, using RSA or DSA keypairs in conjunction with CVS over 
SSH would give you about what you are looking for, and they are used 
when committers make changes to the FreeBSD CVS repository.

Normally, people who checkout the FreeBSD sources via CVS or CVSUP are 
doing so anonymously and without encryption, but it would be possible 
to do a 'cvs checkout' or 'cvs update' via SSH instead.

> Considerable amounts of work into a full-out PKI infrastructure could 
> of
> course also be a problem. All this de facto PGP/GPG stuff just makes my
> head hurt.

RFC-3280 isn't aspirin, unfortunately.  :-)

Using X.509 certs rather than PGP/GPG would change the model of trust 
and perhaps make it a little easier for end-users to verify signed 
content, but that is mostly because end-users are given pre-trusted 
root certificates that SSL certs derive from.

-- 
-Chuck