This should warn that the package is not being verified but has signatures. Maybe --ask can also allow the user to press y to generate keys and enable signature verification. Signature verification seems like an important default. * libnl-3.8.0-3.gpkg.tar MD5 SHA1 size ;-) ... [ ok ] !!! gpg: keyblock resource '/etc/portage/gnupg/pubring.kbx': No such file or directory [GNUPG:] ERROR add_keyblock_resource 33587281 [GNUPG:] PLAINTEXT 74 0 [GNUPG:] NEWSIG gpg: Signature made Mon Mar 25 08:38:50 2024 -00 gpg: using RSA key 534E4209AB49EEE1C19D96162C44695DB9F6043D [GNUPG:] ERROR keydb_search 33554445 [GNUPG:] ERROR keydb_search 33554445 [GNUPG:] ERRSIG 2C44695DB9F6043D 1 10 01 1711355930 9 534E4209AB49EEE1C19D96162C44695DB9F6043D [GNUPG:] NO_PUBKEY 2C44695DB9F6043D gpg: Can't check signature: No public key gpg: can't create `/etc/portage/gnupg/random_seed': No such file or directory !!! Invalid binary package: '/var/cache/binpkgs/dev-libs/libnl/libnl-3.8.0-3.gpkg.tar.partial', GPG verify failed
Hit this today. There is no mention of getuto in the error. Running getuto (which has no man page or help) solves the problem without any output. I very vaguely remember using getuto for initial setup, and was only reminded it exists because another user on IRC ran into this same problem. ---SNIP--- gpg: WARNING: unsafe ownership on homedir '/etc/portage/gnupg' [GNUPG:] PLAINTEXT 74 0 [GNUPG:] NEWSIG gpg: Signature made Tue 02 Apr 2024 10:49:39 AM EDT gpg: using RSA key 534E4209AB49EEE1C19D96162C44695DB9F6043D [GNUPG:] KEYEXPIRED 1719835202 [GNUPG:] KEYEXPIRED 1719835200 [GNUPG:] KEY_CONSIDERED 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910 0 [GNUPG:] KEYEXPIRED 1719835200 [GNUPG:] SIG_ID +qfJvPg3b487tYOkBGcwr7nM03w 2024-04-02 1712069379 [GNUPG:] KEYEXPIRED 1719835202 [GNUPG:] KEYEXPIRED 1719835200 [GNUPG:] KEY_CONSIDERED 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910 0 gpg: Note: trustdb not writable gpg: please do a --check-trustdb [GNUPG:] EXPKEYSIG 2C44695DB9F6043D Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org> gpg: Good signature from "Gentoo Linux Release Engineering (Automated Weekly Release Key) <releng@gentoo.org>" [expired] [GNUPG:] VALIDSIG 534E4209AB49EEE1C19D96162C44695DB9F6043D 2024-04-02 1712069379 0 4 0 1 10 01 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910 [GNUPG:] KEYEXPIRED 1719835202 [GNUPG:] KEYEXPIRED 1719835200 [GNUPG:] KEY_CONSIDERED 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910 0 gpg: Note: This key has expired! Primary key fingerprint: 13EB BDBE DE7A 1277 5DFD B1BA BB57 2E0E 2D18 2910 Subkey fingerprint: 534E 4209 AB49 EEE1 C19D 9616 2C44 695D B9F6 043D gpg: can't create `/etc/portage/gnupg/random_seed': Permission denied !!! Invalid binary package: '/var/cache/binpkgs/dev-python/pytz-2024.1.gpkg.tar.partial', GPG verify failed ---SNIP---
The issue with enabling FEATURES="binpkg-request-signature" by default -> running the trust helper (the default is getuto) is that it breaks anyone doing FEATURES=buildpkg with their own binpkgs. bug 934784 and more so bug 936287 track handling that properly. What happens with the official binpkg host (this bug) is Portage sees a signature, doesn't _require_ it to pass (yet), then bails out because it can't verify the one it does see. The handbook and binpkg guide on the wiki both document the need to run getuto and set binpkg-request-signature, however. (I think there might be a separate issue here -- if you had FEATURES="-binpkg-request-signature" here, then why do we bother running gpg at all?)
(In reply to Sam James from comment #2) > bug 934784 and more so bug 936287 track handling that properly. (Ignore the "more so" or put it in front of the first bug. I changed the order last-minute.)
OK, let's use this bug for tracking the behaviour of FEATURES="-binpkg-request-signature" (where gpg shouldn't be invoked at all, perhaps with a warning that we saw a signature exists but we didn't look at it at all). I've moved the default change into bug 945384.
This is also unfortunate if `gpg` is broken at all (like in the bug 920097 case because of gpg->sqlite->icu).
