Actual behaviour: emerge-webrsync only gives a warning if the downloaded snapshot is signed by any key not trusted. Expected behaviour: emerge-webrsync should abort if a snapshot is signed by any key not trusted to a certain degree. Additionally the behaviour (requested trust level) should be documented in the relevant handbook section: https://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?full=1#webrsync-gpg $ emerge-webrsync Fetching most recent snapshot ... Trying to retrieve 20140103 snapshot from http://distfiles.gentoo.org ... Fetching file portage-20140103.tar.xz.md5sum ... Fetching file portage-20140103.tar.xz.gpgsig ... Fetching file portage-20140103.tar.xz ... Checking digest ... Checking signature ... gpg: Signature made Sat 04 Jan 2014 01:55:06 AM CET using RSA key ID C9189250 gpg: Good signature from "Gentoo Portage Snapshot Signing Key (Automated Signing Key)" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250 Getting snapshot timestamp ... Syncing local tree ...
The problem is: $ gpg --homedir /etc/portage/gpg --verify portage-20140104.tar.xz.gpgsig portage-20140104.tar.xz gpg: Signature made Sun Jan 5 01:55:08 2014 CET using RSA key ID C9189250 gpg: Good signature from "Gentoo Portage Snapshot Signing Key (Automated Signing Key)" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250 $ echo $? 0 Do you know a way to make that fail? Or do you have another suggestion how to detect this case?
How are other distros doing this trick? Debian: https://wiki.debian.org/SecureApt#How_to_tell_apt_what_to_trust Debian Mirror w/ signatures: http://www.tobanet.de/dokuwiki/debian:debmirror gpgv (1) seems to provide a good solution here: Manpage: http://www.tin.org/bin/man.cgi?section=1&topic=gpgv Manual: http://www.gnupg.org/documentation/manuals/gnupg-devel/gpgv.html Conclusion: a) gpgv would provide another way to verify signatures - accessing it's own trustedkeys.db while gpg verifys the signatures - however w/o checking key trust. The gpgv implementation would be somewhat similar on a technical level - just to omit a warning it won't be worth doing that. b) The handbook seem irritating in proposing edit-key trust. The only effect of trusting the key is omitting the warning (decorative effect). Until keys trusting other keys (web of trust) doesn't matter we may stick with status quo. Efforts would be better spent in continuing work on implementing GLEP's eclass Manifest and any kind of MetaManifest and MetaManifest.sig Just in case: to parse gpg output use --status-fd option to get wonderful parseable output.
This is already being worked on: for a python lib wrapping gpg that is able to mine all data from --status-fd and --colon-listing: https://github.com/dol-sen/pyGPG and for gentoo key management there is a project underway. The keys will be changing as well as the methods media will be signed. https://wiki.gentoo.org/wiki/Project:Gentoo-keys Once the new standards have been set by the council, we will begin to make sure infra is set up to be using the new system. There will also be a user installed pkg which will maintain the keys, do the validation, etc..
