keys.openpgp.org to retrieve builder keys
#22688
hkps://hkps.pool.sks-keyservers.net is essentially no-longer functional,
and a number of distributions and GPG tools have since switched to using
the keys.openpgp.org key server as their default.
See this Debian patch for additional context: https://salsa.debian.org/debian/gnupg2/-/blob/debian/main/debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch
Switch to using keys.openpgp.org in the CI as well.
Concept ACK.
Does gpg --refresh-keys also require specifying of a key server?
Concept ACK @hebasto I don’t think it should, but maybe as a precaution (just in case there are any revoked keys, new user IDs, sigs, etc. or if facing remote server issues). Just spitballing here though.
#!/bin/zsh
while read fingerprint keyholder_name
do gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-keys ${fingerprint}
done < ./keys.txt
Also, I tried to run the script above with subset.pool.sks-keyservers.net, and it just returned gpg: keyserver receive failed: No name for all entries in contrib/builder-keys/keys.txt. It only successfully fetched the keys in the file after swapping out the keyserver with keyserver.ubuntu.com:80.
I think SKS is deprecated or something.
Found a related StackExchange question which referenced the following message from ‘https://sks-keyservers.net/ ‘:
0This service is deprecated. This means it is no longer maintained, and new HKPS certificates will not be issued. Service reliability should not be expected.
1
2Update 2021-06-21: Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all.
Just a datapoint: it would seem that since the launch of keys.openpgp.org, many GPG tools and certain distros (Debian, NixOS) have switched over to that as the default server.
Debian switched in July 2019: https://salsa.debian.org/debian/gnupg2/-/blob/01898735a015541e3ffb43c7245ac1e612f40836/debian/NEWS#L10-29
Reproduced:
0 Upstream GnuPG now defaults to not accepting third-party certifications
1 from the keyserver network. Given that the SKS keyserver network is
2 under attack via certificate flooding, and third-party certifications
3 will not be accepted anyway, we now ship with the more tightly-constrained
4 and abuse-resistant system hkps://keys.openpgp.org as the default
5 keyserver.
6
7 Users with bandwidth to spare who want to try their luck with the SKS
8 pool should add the following line to ~/.gnupg/dirmngr.conf to revert to
9 upstream's default keyserver:
10
11 keyserver hkps://hkps.pool.sks-keyservers.net
12
13 See the 2.2.17 section in the upstream NEWS file at
14 /usr/share/doc/gnupg/NEWS.gz for more information about fully
15 reverting to the old, risky behavior.
Their patch (includes more context): https://salsa.debian.org/debian/gnupg2/-/blob/debian/main/debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch
Just a datapoint: it would seem that since the launch of keys.opengpg.org, many GPG tools and certain distros (Debian, NixOS) have switched over to that as the default server.
Looks like keys.opengpg.org also has more of the builder keys available than the Ubuntu server, as well as some newer signatures for keys that are available on either.
I’ve changed this PR to swap both the README and the CI to use keys.opengpg.org.
19@@ -20,7 +20,7 @@ To fetch keys of builders and active developers, feed the list of fingerprints
20 of the primary keys into gpg:
21
22 ```sh
23-while read fingerprint keyholder_name; do gpg --keyserver hkp://subset.pool.sks-keyservers.net --recv-keys ${fingerprint}; done < ./keys.txt
24+while read fingerprint keyholder_name; do gpg --keyserver hkps://keys.openpgp.org --recv-keys ${fingerprint}; done < ./keys.txt
Are all builder keys on that keyserver? IIRC only persons with access to the email that the key is attached to can upload there.
Also the src/minisketch/test file added in this pull seems unrelated.
Nvm, just read your previous comment:
Looks like keys.opengpg.org also has more of the builder keys available than the Ubuntu server, as well as some newer signatures for keys that are available on either.
but the exe should be removed
Done. Not sure how I didn’t notice that. Fixed the commit message typo as well.
hkps://hkps.pool.sks-keyservers.net is essentially no-longer functional,
It kind of gives me the feeling that we keep migrating from keyserver to keyserver as they become no-longer functional one by one.
But sure if it’s needed it’s needed. I don’t see any better solution to this mess, mind you.
contrib/verify-commits/README.md. Maybe replace this one too?
contrib/verify-commits/README.md might as well be updated too. More generally, though, I see moving to keys.openpgp.org as more of an LTS move; I don’t think the keyserver will be down anytime soon.
hkps://hkps.pool.sks-keyservers.net is essentially no-longer functional,
and a number of distributions and GPG tools have since switched to using
this key server as their default.
See this Debian patch for additional context:
https://salsa.debian.org/debian/gnupg2/-/blob/debian/main/debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch
Switch to using keys.openpgp.org in the CI as well.
FWIW, there’s another mention of keyserver in contrib/verify-commits/README.md. Maybe replace this one too?
Thanks. Have replaced that as well.