(possibly metadata.xml instead) Currently, we're expecting the developers to manually ensure upstream tarball validity. However, considering that some upstreams do provide GPG signatures for their software and others provide various checksums, I think it would be beneficial if we were able to provide links/patterns for those checksums and PM would be able to fetch and check them.
The gentoo-keys project [1] was originally meant to manage gentoo's gpg keys. It does this through use of seed files which contain information about the gpg key. That info is used to download and install the gpg key(s) onto a system from a keyserver. It then provides both an command line interface and a python API to manage those keys and perform verification of release media, git commits, etc.. Since the majority of the code will be in place already for other tasks. It will be easy to extend it's capability to be used for packages as well. While the normal method is for it to obtain the seed info from a seed file which can be updated from api.gentoo.org similar to the repositories.xml file for layman. The seed info for a pkg could be added to it's metadata.xml. The package manager would supply that info to a gkeys lib instance api function which could automatically check if the key was installed, import it if not already, then verify the contents of the sources. Also a GPG_URI could be added (possibly) to the packages ebuild for the eclass/package manager to download. It would be the detached gpg signature for the sources. That signature could then be used to verify the source. This would also provide a method of not requiring to download and create a manifest for the source. So, along the lines of a thin-manifest. A package could be created with no need for a distfile manifest entry. [1] http://git.overlays.gentoo.org/gitweb/?p=proj/gentoo-keys.git;a=summary
Note that we now have verify-sig.eclass, but it's not a replacement for PMS 'support'.
(In reply to Sam James from comment #2) > Note that we now have verify-sig.eclass, but it's not a replacement for PMS > 'support'. I don't think this fits the idea of generic/compact things we want in the PMS. After all, verify-sig right now supports two kinds of signatures already (detached and signed *sum files), there's use of on-the-fly unpacking+verification (in vanilla-kernel), there's a request for minisig format...
