packages, libfetch, and SSL

[David E. Thiel]

Hello,

I've been doing some thinking about the security of the packages and
ports system, and have noticed that there is something of a weak link
when it comes to fetch/libfetch in general, and the way we do pkg_adds
in particular. While updates to the ports tree happen in a pretty secure
manner over portsnap, and distfiles are verified during the build
process, packages added over pkg_add -r happen over plain FTP or HTTP
without any verification, allowing packages to be swapped or corrupted
by a network attacker.

The lowest-impact way to fix this, I think, is to use SSL for pkg_adds.
There are a couple of things that would need to change to make this
happen.

* Package distribution sites should use SSL over HTTP. Yes, this costs
money. We can either find a way to use a free solution or get people to
chip in - I'd gladly put some money up for this.

* libfetch needs patched to verify SSL certificate CNs and to use
SSL_CTX_set_verify on SSL contexts. It should really be considered
a vulnerability that this currently doesn't happen, since SSL is
meaningless without this. This is easy enough to fix (about 10 lines in
libfetch/common.c), but is currently not feasible because:

* CA certificates are not in the base system. CA certs are currently
available in the security/ca_root_nss port. Is this suitable for
importing to base? If not, why not?

Now, we could take another approach of PGP-signing packages instead, but
all the efforts I've seen to integrate PGP with the package management
system in the past haven't gone anywhere. The changes above seem to be
a bit more trivial than inventing a package-signing infrastructure and
putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign
packages and having a baked-in key would work as well.

If we don't want to do any of this, I at least think that the current
SSL support in libfetch should be removed entirely, or be accompanied
by a very noisy error.

Any thoughts?

Cheers,
David