I scanned quickly over GLEP 57-61 and noticed that it only tackles the gentoo inner security and doesn't deal with the upstream -> gentoo process (aka. gentoo dev preparing the ebuild and in this process generating the strong hashes). It seems to be a good idea to provide an easy way to check for the gentoo dev whether his upstream provided a tarball with verified authenticity and integrity. Problem is that from time to time some of the upstream tarball distribution servers are compromised and files are replaced with slightly modified versions which contain backdoors. Without an easy strategy, such attacks might be undetected by the Gentoo dev and therefore get inserted in the gentoo mirror system and from there into the user system. Here is a bug report which should explain the strategy from Debian and Ubuntu (first one is a too complex one which was replaced with an easier approach that is now implemented): http://bugs.debian.org/610712
Here are some infos from the Arch people: http://allanmcrae.com/2012/04/how-secure-is-the-source-code/
Here are some bits from the OpenSUSe guys http://lists.opensuse.org/opensuse-factory/2012-12/msg00235.html
We can store the upstream key information in package's metadata.xml file.
*** Bug 598589 has been marked as a duplicate of this bug. ***
(In reply to Zac Medico from comment #3) > We can store the upstream key information in package's metadata.xml file. Isn't this responsibility of package maintainers to check when updating package to begin with rather than something that should be implemented technically? Keys change, method of verification can differ between packages (signed text document containing SHA256 sum vs detached signature vs inline binary signature etc) Any technical solution to this is likely more complex than necessary for what should be checked to begin with.
(In reply to Kristian Fiskerstrand from comment #5) > Any technical solution to this is likely more complex than necessary for > what should be checked to begin with. Yeah, maybe if there was some sort of cross-distro verification standard available. It seems like it would require a lot of cooperation with upstream projects it order to be really practical. It would be interesting to see statistics on actually provide signatures for their release files.
(In reply to Zac Medico from comment #6) > (In reply to Kristian Fiskerstrand from comment #5) > > Any technical solution to this is likely more complex than necessary for > > what should be checked to begin with. > > Yeah, maybe if there was some sort of cross-distro verification standard > available. It seems like it would require a lot of cooperation with upstream > projects it order to be really practical. It would be interesting to see > statistics on actually provide signatures for their release files. Might make sense to document a preference in devmanual, but sadly quite a few projects do not provide OpenPGP signatures, and plenty of devs do not properly validate keys used for the signatures rendering it a bit moot to begin with. But I believe it is a social issue and not a technical one.
I think this is essentially done with the verify-sig eclass.