I'm trying to publish my renewed key to the Gentoo keyserver, and it seems to fail for hkps://motmot.keys.gentoo.org as follows: gpg --export D075FB8C104A3D20 | ssh dev.gentoo.org /usr/local/bin/openpgp-key-upload (reading key material from stdin) gpg: keybox '/tmp/tmp.MucsYVO8ax/pubring.kbx' created gpg: /tmp/tmp.MucsYVO8ax/trustdb.gpg: trustdb created gpg: key D610CF3721E78ACD: public key "Zachary Medico <zmedico@gentoo.org>" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: sending key D610CF3721E78ACD to hkps://kookaburra.keys.gentoo.org gpg: sending key D610CF3721E78ACD to hkps://motmot.keys.gentoo.org gpg: signal Terminated caught ... exiting gpg: sending key D610CF3721E78ACD to hkps://trogan.keys.gentoo.org Reproducible: Always Steps to Reproduce: 1. Invoke openpgp-key-upload Actual Results: It appears that my key is not renewed because I get a warning when I push to gentoo.git: remote: D610CF3721E78ACD [Zachary Medico <zmedico@gentoo.org>] [W] expire:short Expiration date is close, please renew (is 2022-11-02 16:32:58, less than 28 days) remote: D610CF3721E78ACD:D075FB8C104A3D20 [Zachary Medico <zmedico@gentoo.org>] [W] expire:short Expiration date is close, please renew (is 2022-11-01 16:35:13, less than 28 days) Expected Results: My key should be renewed.
mpagano had a similar problem a few days ago.
Looks like the key made it to the keyservers. $ gpg --keyserver hkps://keys.gentoo.org --recv-key D075FB8C104A3D20 gpg: key D610CF3721E78ACD: "Zachary Medico <zmedico@gentoo.org>" 4 new signatures gpg: Total number processed: 1 gpg: new signatures: 4 $ gpg --list-key zmedico@gentoo.org pub rsa4096 2018-07-03 [SC] [expires: 2025-03-23] 4758ACD8DA9AFD46A6A6040AD610CF3721E78ACD uid [ unknown] Zachary Medico <zmedico@gentoo.org> uid [ unknown] Zachary Medico <zmedico@gmail.com> sub rsa4096 2018-07-03 [E] [expires: 2025-03-23] 43262F80D306650C90D79F8D293070BCDC358183 sub rsa4096 2018-07-03 [S] [expires: 2025-03-23] F0E8176A5B56CEA812BA90AED075FB8C104A3D20 So I suppose this is the same issue we've seen happen to other people so far - qa-reports.gentoo.org isn't properly refreshing the keys before creating the keyrings that are ingested by the gitolite servers. Indeed: $ curl -s https://qa-reports.gentoo.org/output/active-devs.gpg | gpg --show-keys [...] pub rsa4096 2018-07-03 [SC] [expires: 2022-11-02] 4758ACD8DA9AFD46A6A6040AD610CF3721E78ACD uid Zachary Medico <zmedico@gentoo.org> uid Zachary Medico <zmedico@gmail.com> sub rsa4096 2018-07-03 [E] [expires: 2022-11-01] 43262F80D306650C90D79F8D293070BCDC358183 sub rsa4096 2018-07-03 [S] [expires: 2022-11-01] F0E8176A5B56CEA812BA90AED075FB8C104A3D20 [...]
gqa@motmot ~ $ DEBUG=1 /usr/bin/nice /usr/local/bin/pidlock /var/www/qa-reports.gentoo.org/qa-scripts/keyrings-recv-keys.gentoo.org.bash DEBUG: pidlock: Not running already, putting PID in pidfile DEBUG: pidlock: Doing something (/var/www/qa-reports.gentoo.org/qa-scripts/keyrings-recv-keys.gentoo.org.bash) SYSTEM_KEYS gpg: keyserver receive failed: No keyserver available COMITTING_DEVS gpg: keyserver receive failed: No keyserver available NONCOMITTING_DEVS gpg: keyserver receive failed: No keyserver available INFRA_DEVS gpg: keyserver receive failed: No keyserver available DEBUG: pidlock: Cleaning up /tmp/gqa/pidlock-keyrings-recv-keys.gentoo.org.bash.pid But, seems to work when doing it manually: ajak@motmot ~ $ gpg --keyserver hkps://motmot.keys.gentoo.org --recv-keys 4758ACD8DA9AFD46A6A6040AD610CF3721E78ACD gpg: key D610CF3721E78ACD: "Zachary Medico <zmedico@gentoo.org>" 4 new signatures gpg: Total number processed: 1 gpg: new signatures: 4
Killing gqa's dirmngr process seems to have helped things enough to mostly consistently receive keys from hkps://motmot.keys.gentoo.org, but this hasn't helped enough to get keys quickly enough to avoid the timeout. Currently timing a --recv-key of a bunch of keys to see how long it's actually taking without the timeout, already going for several minutes...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/qa-scripts.git/commit/?id=1731d58dd5b7cffbb6bd8dc3bd49e9e8642b814f commit 1731d58dd5b7cffbb6bd8dc3bd49e9e8642b814f Author: John Helmert III <ajak@gentoo.org> AuthorDate: 2022-10-10 23:53:44 +0000 Commit: John Helmert III <ajak@gentoo.org> CommitDate: 2022-10-10 23:56:01 +0000 keyrings: disable using local keyserver Somehow this is vastly, vastly slower than simply using keys.gentoo.org even though they should be resolving to the same host. Bug: https://bugs.gentoo.org/876532 Signed-off-by: John Helmert III <ajak@gentoo.org> keyrings.inc.bash | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
With this command: time gpg --keyserver hkps://motmot.keys.gentoo.org --recv-keys 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910 18F703D702B1B9591373148C55D3238EC050396E 2C13823B8237310FA213034930D132FF0FF50EEB ABD00913019D6354BA1D9A132839FE0D796198B1 BA9A03F6BE9C0CA405C17BFE079BA8929AF1275A D99EAC7379A850BCE47DA5F29E6438C817072058 DCD05B71EAB94199527F44ACDB6B8C1F96D8BF6D EF9538C9E8E64311A52CDEDFA13D0EF1914E7A72 I got 17 minutes and then 13 minutes on sks-1.1.6-r2, then 14.5 minutes after upgrading sks. 3 seconds if I use keys.gentoo.org.
Looks like qa-reports is showing the right key now, let us know if gitolite stops complaining?
Yeah, gitolite has stopped complaining. Thanks!
Thanks! Seems like motmot is healthier in general now that bug 875800 is solved.
