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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
