perhaps to keep the clutter down in the eclasses folder we could use a subdir eutils.eclass's Manifest would be here for example: eclass/Manifests/eutils this should be pretty high priority because eclasses provide an easy way to subvert the security provided by Manifests for ebuilds
*** Bug 45692 has been marked as a duplicate of this bug. ***
*** Bug 371161 has been marked as a duplicate of this bug. ***
Checksums are easy to do. For gpg signatures, we'll need PMS to specify how verification is supposed to work.
I guess a GLEP would be enough.
*** Bug 482630 has been marked as a duplicate of this bug. ***
So I'm taking the discussion from https://bugs.gentoo.org/show_bug.cgi?id=64258 to here. (In reply to Jeroen Roovers from comment 64258 - #2) > That is similarly untrue: if you change $EBUILD and then run `ebuild $EBUILD > manifest', you're in the same boat. Manifest signing would help there but we > still cannot rely on that now. I agree with you with the fact that if an attacker have local access to the computer that he could simply run `ebuild $EBUILD manifest' and the user won't notice that. But when he's already got local access to a computer there are easier ways than manipulating something in the local portage dir. But that's not the security hole I thought. In my scenario the attacker only have access to a gentoo mirror and can just edit the eclass-files without any acknowledge and security check. Only a simple file edit could infect thousands of gentoo systems in a short time. The checksums which are generated for ebuilds could remove this attacking scenario completely.
We can use GLEP 74 manifests for this, but we need to make sure that it doesn't interfere with manifest generation for the rsync tree.
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
