-
Notifications
You must be signed in to change notification settings - Fork 38.7k
contrib: use keys.openpgp.org to retrieve builder keys
#22688
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Concept ACK. Does |
|
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. fetch_keys.shAlso, I tried to run the script above with |
|
I think SKS is deprecated or something. Found a related StackExchange question which referenced the following message from 'https://sks-keyservers.net/ ': |
|
ACK 641155a |
|
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: 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 |
641155a to
b4f1f99
Compare
keyserver.ubuntu.com to retrieve builder keyskeys.openpgp.org to retrieve builder keys
Looks like I've changed this PR to swap both the README and the CI to use |
keys.openpgp.org to retrieve builder keyskeys.openpgp.org to retrieve builder keys
|
Approach ACK b4f1f998236ab1ae44a1a3c8ae84213474cae4dc, but the exe should be removed |
b4f1f99 to
a3e4ff6
Compare
Done. Not sure how I didn't notice that. Fixed the commit message typo as well. |
|
cr ACK a3e4ff63e3e5bd5fb46f872c59d3ca74f81c56fa |
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. |
|
FWIW, there's another mention of keyserver in |
|
Yeah, I think |
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.
a3e4ff6 to
4c43b7d
Compare
Thanks. Have replaced that as well. |
|
cr ACK 4c43b7d |
Zero-1729
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 4c43b7d
…eve builder keys 4c43b7d contrib: use hkps://keys.openpgp.org to retrieve builder keys (fanquake) Pull request description: `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. ACKs for top commit: MarcoFalke: cr ACK 4c43b7d Zero-1729: ACK 4c43b7d Tree-SHA512: e6c72b67778b76f81c659eee0e4195fea9e579587c64921affd35b9d46a077d4e8754b7fb85ca90a9a4bbc5cd5a47b0c6e4c9dbf9a335418a12f774d665e5a19
|
This was merged in fdd80b0. |
…der keys 4c43b7d contrib: use hkps://keys.openpgp.org to retrieve builder keys (fanquake) Pull request description: `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. ACKs for top commit: MarcoFalke: cr ACK 4c43b7d Zero-1729: ACK 4c43b7d Tree-SHA512: e6c72b67778b76f81c659eee0e4195fea9e579587c64921affd35b9d46a077d4e8754b7fb85ca90a9a4bbc5cd5a47b0c6e4c9dbf9a335418a12f774d665e5a19
…Y.md 90f1f84 doc: Suggest `keys.openpgp.org` as keyserver in SECURITY.md (Tim Ruffing) Pull request description: `--recv-keys` without a `--keyserver` arg simply failed for me on a fresh Arch Linux installation, so I think it's a good idea to suggest a keyserver. OpenPGP ecosystem is broken in a number of ways, so the right way to approach this issue has some potential for bikeshedding. But the only thing that this PR does is to keep `SECURITY.md` in line with the instructions for builder keys, where there was agreement on switching to `keys.openpgp.org` (#22688). ACKs for top commit: MarcoFalke: review ACK 90f1f84 laanwj: Review ACK 90f1f84 hebasto: ACK 90f1f84, agree with arguments above. Zero-1729: ACK 90f1f84 Tree-SHA512: 1ab20c837cd952aa32b57473772cbfd33411a08db6e88b951bce38f76a3c509c0e91d6944ec0ca5eac8d5eb4d98a5489276d55691328f2e2556b2640f8e7c108
…SECURITY.md 90f1f84 doc: Suggest `keys.openpgp.org` as keyserver in SECURITY.md (Tim Ruffing) Pull request description: `--recv-keys` without a `--keyserver` arg simply failed for me on a fresh Arch Linux installation, so I think it's a good idea to suggest a keyserver. OpenPGP ecosystem is broken in a number of ways, so the right way to approach this issue has some potential for bikeshedding. But the only thing that this PR does is to keep `SECURITY.md` in line with the instructions for builder keys, where there was agreement on switching to `keys.openpgp.org` (bitcoin#22688). ACKs for top commit: MarcoFalke: review ACK 90f1f84 laanwj: Review ACK 90f1f84 hebasto: ACK 90f1f84, agree with arguments above. Zero-1729: ACK 90f1f84 Tree-SHA512: 1ab20c837cd952aa32b57473772cbfd33411a08db6e88b951bce38f76a3c509c0e91d6944ec0ca5eac8d5eb4d98a5489276d55691328f2e2556b2640f8e7c108
…SECURITY.md 90f1f84 doc: Suggest `keys.openpgp.org` as keyserver in SECURITY.md (Tim Ruffing) Pull request description: `--recv-keys` without a `--keyserver` arg simply failed for me on a fresh Arch Linux installation, so I think it's a good idea to suggest a keyserver. OpenPGP ecosystem is broken in a number of ways, so the right way to approach this issue has some potential for bikeshedding. But the only thing that this PR does is to keep `SECURITY.md` in line with the instructions for builder keys, where there was agreement on switching to `keys.openpgp.org` (bitcoin#22688). ACKs for top commit: MarcoFalke: review ACK 90f1f84 laanwj: Review ACK 90f1f84 hebasto: ACK 90f1f84, agree with arguments above. Zero-1729: ACK 90f1f84 Tree-SHA512: 1ab20c837cd952aa32b57473772cbfd33411a08db6e88b951bce38f76a3c509c0e91d6944ec0ca5eac8d5eb4d98a5489276d55691328f2e2556b2640f8e7c108
hkps://hkps.pool.sks-keyservers.netis essentially no-longer functional,and a number of distributions and GPG tools have since switched to using
the
keys.openpgp.orgkey 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.