Being able to verify the signature on a stage is insufficient to ensure it is genuine. All that the verified signature says is that the file is identical to the file when the person signed it. It says nothing about whether the signer is actually Gentoo Release Engineering. There are two ways to address this. One is through the Web of Trust model of gpg. Most users don't have connections in the Web of Trust to enable them to authenticate the signing key's fingerprint. This is where https comes in. The page at http://www.gentoo.org/proj/en/releng lists the key fingerprints. However, that page is not available over https. This means I have no way to know if that's legitimately content from www.gentoo.org. For that reason, that page needs to be made available over HTTPS, and it needs to use a certificate that's commonly trusted. If you use a CACert certificate, you end up with the same problem because now you have to figure out a way to know if the CACert certificate is authentic. Even if their root CACert certificate is authentic, you have to verify their intermediate certificate is authentic because it is signed by the root certificate using MD5 which has forgability issues. Reproducible: Always Steps to Reproduce: 1. Try visiting https://www.gentoo.org/proj/en/releng so you have a secured, authenticated connection. Actual Results: Nothing is listening for https. Expected Results: The page is available over https using a certificate from a commonly trusted authority.
And plenty of commercial CAs have LOTS of other problems in their validation process, some of them are using MD5 on their root CAs as well still. I'll deploy SSL w/ CACert, but we're not going to buy any commercial certificates at all. Both their Class 1 and Class 3 certificates are still on MD5.
Cool, it's a step in a better direction.
HTTPS is in place now on www.gentoo.org
