Did a repo sync and it seems that the keys in this package have expired: $ emerge --sync ... !!! Manifest verification failed: OpenPGP signature rejected because of expired key: gpg: Signature made Sat Jan 1 17:39:10 2022 UTC gpg: using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250 gpg: Good signature from "Gentoo ebuild repository signing key (Automated Signing Key) <infrastructure@gentoo.org>" [expired] gpg: aka "Gentoo Portage Snapshot Signing Key (Automated Signing Key)" [expired] gpg: Note: This key has expired! 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
1. What version of gemato & portage do you have? 2. Please provide emerge --info 3. Can you verify that your sync-openpgp-key-refresh is still enabled in repos.conf? 4. Does the rest of the emerge --sync output say anything ELSE earlier about refreshing keys? It should have refreshed the keys via WKD and/or the keyservers, all of which are updated and provide continuity of key validity.
(In reply to Robin Johnson from comment #1) > 1. What version of gemato & portage do you have? gemato-16.2 and portage-3.0.28-r1. > 3. Can you verify that your sync-openpgp-key-refresh is still enabled in > repos.conf? This is explicitly disabled on my server systems has most of them sit behind strict firewalls (not even outbound HTTPS is allowed). > 4. Does the rest of the emerge --sync output say anything ELSE earlier about > refreshing keys? > > It should have refreshed the keys via WKD and/or the keyservers, all of > which are updated and provide continuity of key validity. Normally yes, but some of us still rely on a key on the local filesystem. I have verified that sec-keys/openpgp-keys-gentoo-release-20220101 fixed the issue.
Ok, so I think a few options we could mention are: 1) Copying /usr/share/openpgp-keys/gentoo-release.asc from a Gentoo system that has the new openpgp-keys-gentoo-release. 2) Fetching the respective bundle directly from gentoo.org, i.e.: wget -O /usr/share/openpgp-keys/gentoo-release.asc \ https://qa-reports.gentoo.org/output/service-keys.gpg (NB: technically this is not ASCII-armored format but Portage doesn't care) 3) Manually refreshing the respective key, i.e.: gpg --import /usr/share/openpgp-keys/gentoo-release.asc gpg --keyserver hkps://keys.gentoo.org --refresh-keys <keyid> gpg -a --export <keyid> > /usr/share/openpgp-keys/gentoo-release.asc Then --sync and upgrade sec-keys/openpgp-keys-gentoo-release. Not sure if option 3) is worth mentioning as it's relatively harder.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=403d73ac4e5531ae05233a88d4d6211977ba8d1c commit 403d73ac4e5531ae05233a88d4d6211977ba8d1c Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-24 10:43:21 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-12-24 10:43:21 +0000 sys-apps/portage: tighten sec-keys/openpgp-keys-gentoo-release dependency bound Bug: https://bugs.gentoo.org/730642 Bug: https://bugs.gentoo.org/830418 Signed-off-by: Sam James <sam@gentoo.org> .../portage/{portage-3.0.38.1-r4.ebuild => portage-3.0.38.1-r5.ebuild} | 2 +- sys-apps/portage/{portage-3.0.41.ebuild => portage-3.0.41-r1.ebuild} | 2 +- sys-apps/portage/portage-9999.ebuild | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-)
