The listed key for the "Gentoo ebuild repository signing key" will expire today according to the URL mentioned above. I assume this bug https://bugs.gentoo.org/659806 was supposed to warn about expiring infrastructure related GPG keys? This is what I get with gpg: ######################################### # gpg --keyserver hkps.pool.sks-keyservers.net --recv-keys DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D gpg: key DB6B8C1F96D8BF6D: 15 signatures not checked due to missing keys gpg: key DB6B8C1F96D8BF6D: public key "Gentoo ebuild repository signing key (Automated Signing Key) <infrastructure@gentoo.org>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 # gpg --list-keys /root/.gnupg/pubring.kbx ------------------------ pub rsa4096 2011-11-25 [C] [expires: 2019-01-01] DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D uid [ unknown] Gentoo ebuild repository signing key (Automated Signing Key) <infrastructure@gentoo.org> uid [ unknown] Gentoo Portage Snapshot Signing Key (Automated Signing Key) sub rsa4096 2011-11-25 [S] [expires: 2019-01-01] # ######################################### Will portage keep working after the key expired? What's the workaround if portage stops working? Also just now when trying to submit bugzilla told me that it couldn't find "infrastructure@gentoo.org" (I had it in CC)
confirm !!! Manifest verification failed: OpenPGP signature rejected because of expired key:
I extended the key to 2020 and pushed it to keyservers. -A
(In reply to Alec Warner from comment #2) > I extended the key to 2020 and pushed it to keyservers. Please push it to the WKD. $ gpg --locate-keys infrastructure@gentoo.org pub rsa4096/0xDB6B8C1F96D8BF6D 2011-11-25 [C] [expired: 2019-01-01] DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D uid [ expired] Gentoo ebuild repository signing key (Automated Signing Key) <infrastructure@gentoo.org>
Hi folks, As a Gentoo Linux user, what can I do to fix my environment? And what can I do to prevent such issues in the future? Thanks!
(In reply to Alexander Tsoy from comment #3) > (In reply to Alec Warner from comment #2) > > I extended the key to 2020 and pushed it to keyservers. > Please push it to the WKD. > > $ gpg --locate-keys infrastructure@gentoo.org > pub rsa4096/0xDB6B8C1F96D8BF6D 2011-11-25 [C] [expired: 2019-01-01] > DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D > uid [ expired] Gentoo ebuild repository signing key > (Automated Signing Key) <infrastructure@gentoo.org> FTR, --locate-keys uses WKD only if the key is not present locally. Afterwards, it just prints the local copy. The usual method of fixing this is to use: $ gpg --refresh DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D FWICS, it fetched the new key from keyservers for me already, so it was sent there and it's just a matter of propagation. Gentoo keyrings and WKD will be updated when cronjob fetches new keys which should take no more than a few hours. You may also consider using git sync, as it uses a different key which is effectively going to work around the propagation delay.
*** Bug 674276 has been marked as a duplicate of this bug. ***
I'm not seeing a new key on the keyserver I use. ``` # gpg --search infrastructure@gentoo.org gpg: data source: http://51.38.91.189:11371 (1) Gentoo Portage Snapshot Signing Key (Automated Signing Key) Gentoo ebuild repository signing key (Automated Signing Key) <infrastr 4096 bit RSA key DB6B8C1F96D8BF6D, created: 2011-11-25, expires: 2019-01-01 (expired) (2) Benjamin Coles (Gentoo Infrastructure) <sj7trunks@gentoo.org> 1024 bit DSA key B2351D8734B61EA1, created: 2003-09-22 Keys 1-2 of 2 for "infrastructure@gentoo.org". Enter number(s), N)ext, or Q)uit > n # ```
The new key is available when using gpg: ############################################# # gpg --refresh DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D gpg: refreshing 1 key from hkps://hkps.pool.sks-keyservers.net gpg: key DB6B8C1F96D8BF6D: 15 signatures not checked due to missing keys gpg: key DB6B8C1F96D8BF6D: "Gentoo ebuild repository signing key (Automated Signing Key) <infrastructure@gentoo.org>" 2 new signatures gpg: Total number processed: 1 gpg: new signatures: 2 gpg: no ultimately trusted keys found # gpg --list-keys /root/.gnupg/pubring.kbx ------------------------ pub rsa4096 2011-11-25 [C] [expires: 2020-01-01] DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D uid [ unknown] Gentoo ebuild repository signing key (Automated Signing Key) <infrastructure@gentoo.org> uid [ unknown] Gentoo Portage Snapshot Signing Key (Automated Signing Key) sub rsa4096 2011-11-25 [S] [expires: 2020-01-01] # ############################################# But when syncing the portage tree it's not available yet: ############# snip ############# >>> Syncing repository 'gentoo' into '/usr/portage'... * Using keys from /usr/share/openpgp-keys/gentoo-release.asc * Refreshing keys from keyserver ... [ ok ] >>> Starting rsync with rsync://193.1.193.64/gentoo-portage... >>> Checking server timestamp ... ############# snip ############# * Manifest timestamp: 2019-01-01 11:38:39 UTC * Valid OpenPGP signature found: * - primary key: DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D * - subkey: E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250 * - timestamp: 2019-01-01 11:38:39 UTC * Verifying /usr/portage/.tmp-unverified-download-quarantine ...!!! Manifest verification failed: ############# snip ############# I guess we'll have to wait for the mirrors to catch up?
(In reply to Aliaksei Urbanski from comment #4) > Hi folks, > > As a Gentoo Linux user, what can I do to fix my environment? > And what can I do to prevent such issues in the future? > > Thanks! You can cleanup the "/usr/portage" folder, e.g. "rm -rf /usr/portage" if it's not a mountpoint, and use the Portage Tarball after verifying it via gnupg: ~ # tar xvjf /tmp/portage-latest.tar.bz2 -C /usr OR ~ # tar xvJf /tmp/portage-latest.tar.xz -C /usr Make sure to adjust paths as needed. Source: https://web.archive.org/web/20081017141338/http://www.gentoo.org:80/doc/en/handbook/handbook-amd64.xml?full=1#book_part1_chap5__chap3_pre4
If you have Portage version 2.3.21+ an "emerge --sync" or "eix-sync" should be enough. Source: https://wiki.gentoo.org/wiki/Project:Portage/Repository_Verification
(In reply to David Sardari from comment #9) > (In reply to Aliaksei Urbanski from comment #4) > > Hi folks, > > > > As a Gentoo Linux user, what can I do to fix my environment? > > And what can I do to prevent such issues in the future? > > > > Thanks! > > You can cleanup the "/usr/portage" folder, e.g. "rm -rf /usr/portage" if > it's not a mountpoint, and use the Portage Tarball after verifying it via > gnupg: > > ~ # tar xvjf /tmp/portage-latest.tar.bz2 -C /usr > > OR > > ~ # tar xvJf /tmp/portage-latest.tar.xz -C /usr > > Make sure to adjust paths as needed. > > Source: > https://web.archive.org/web/20081017141338/http://www.gentoo.org:80/doc/en/ > handbook/handbook-amd64.xml?full=1#book_part1_chap5__chap3_pre4 Hello David, Thank you for the suggestion, but why is it based on article from 2008 which is in Web Archive? As for me, removing of /usr/portage in this case looks like an overkill. I already fixed my environment by just waiting and running "emaint sync -A". But thank you anyway!
(In reply to Aliaksei Urbanski from comment #4) > Hi folks, > > As a Gentoo Linux user, what can I do to fix my environment? > And what can I do to prevent such issues in the future? > > Thanks! This issue is not preventable by end users. You should be able to just emerge --sync and it should refresh the signing keys automatically.
(In reply to Aliaksei Urbanski from comment #11) > Hello David, > > Thank you for the suggestion, but why is it based on article from 2008 which > is in Web Archive? > As for me, removing of /usr/portage in this case looks like an overkill. > I already fixed my environment by just waiting and running "emaint sync -A". > > But thank you anyway! Hi Aliaksei, this used to be a valid option when portage (version <=2.3.20) was not able to verify "/usr/portage". At that time, I personally used "FEATURE='webrsync-gpg'". But, with portage version 2.3.21+ this became obsolete. It come in handy if you somehow mess up "/usr/portage" though.
*** Bug 675134 has been marked as a duplicate of this bug. ***
