[I don’t know if this is the right product/component, as it is a portage, security and website problem. I chose this one because other bugs with “rsync-verify” were found here. Feel free to move it to the right place, if necessary.] The news text suggest “verifying” the keys, using the website, on first use. But this requires the website itself to be verified to be trustworthy. Something that is not the case. The website itself is “verified” by a ‘Let’s encrypt’ certificate, using TLS. Which itself is “verified” by ‘Digital Signature Trust Co.’. Which is built into the browser (without even telling the user). (!!) But the browser itself came from the repository, or a source that was either untrusted or “verified” using the same merely partial mechanism, leading back to the browser’s built-in root certificates. These root certificates are never checked by the end user. They are just imposed on the user by an entity that was itself never verified and is not known to the user personally. Resulting in the same problem back again, that the entire plan (I presume) was intended to solve. So this can still be exploited in the exact same way, as it has been, many times before, by undermining the blindly trusted verifier … which before was the Portage repository, and in this case is the browser, or one of the many root CAs that are deemed trustworthy without any motivation or reason for the end user to do so. (Including getting one’s own added.) The news should not suggest this method, let alone call it a verification, to avoid a false sense of security and security theater that leads to people trusting in it and becoming less careful, which actually *increases* the risk. The website should also not present it in such a light. The actual solution is personal eye-to-eye verification between both sides, and *only* that. If necessary is practice, via a chain of personally trusted people, as short as possible. Until then, the action should be considered merely handing the trust assessment to the CAs / browser makers. With the info, in LARGE RED LETTERS, that said entities themselves must be checked in the first place, in order to provide any trustworthiness different from zero. Reproducible: Always Steps to Reproduce: 1. Look up the methods to create false certificates, using a browser-built-in root CA, used by the many previous cases. 2. Apply those methods (like social engineering, simple security exploits, or just using the most shady or incompetent CA on the list), to create a false root CA for www.gentoo.org. 3. Set up a HTTPS MITM and alter requests to https://www.gentoo.org/downloads/signatures/ to show your own key’s signatures. 4. Have the MITM also inject a payload and this new verification data into the Portage rsync. 5. Let the user “verify” the bogus signature to the one on the bogus website. 6. Wait for the user to install the payload, inserted into one of the core system packages. Actual Results: You now have root access to the user’s system and an inside view to his network neighborhood. Expected Results: The user should verify the signature against one obtained directly from a trustworthy person, e.g. a friend who is a member at his local Linux users group, who himself personally met a key Gentoo Portage repository maintainer who has control and oversight over the repository. Since it would not match, the user would reject the updates.
I'm sorry but we are aiming for reasonably secure model, not paranoia. Things aren't perfect and they will never be, and just replacing one attack vector with another doesn't change them. I would also point out that you're wrongly presuming that all software using for verification (which was obviously installed from the repository beforehand), as well as the compiler in use, and the compiler used to create that one, and all hardware involved in this very complex process was secure.
