contrib: use `keys.openpgp.org` to retrieve builder keys by fanquake · Pull Request #22688 · bitcoin/bitcoin

fanquake · 2021-08-12T08:45:18Z

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.

hebasto · 2021-08-12T08:48:02Z

Concept ACK.

Does gpg --refresh-keys also require specifying of a key server?

Zero-1729 · 2021-08-12T10:20:36Z

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.sh

#!/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.

Zero-1729 · 2021-08-12T10:25:46Z

I think SKS is deprecated or something.

Found a related StackExchange question which referenced the following message from 'https://sks-keyservers.net/ ':

This service is deprecated. This means it is no longer maintained, and new HKPS certificates will not be issued. Service reliability should not be expected.

Update 2021-06-21: Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all.

jamesob · 2021-08-12T20:23:42Z

ACK 641155a

dongcarl · 2021-08-13T19:52:14Z

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:

  Upstream GnuPG now defaults to not accepting third-party certifications
  from the keyserver network.  Given that the SKS keyserver network is
  under attack via certificate flooding, and third-party certifications
  will not be accepted anyway, we now ship with the more tightly-constrained
  and abuse-resistant system hkps://keys.openpgp.org as the default
  keyserver.

  Users with bandwidth to spare who want to try their luck with the SKS
  pool should add the following line to ~/.gnupg/dirmngr.conf to revert to
  upstream's default keyserver:

      keyserver hkps://hkps.pool.sks-keyservers.net

  See the 2.2.17 section in the upstream NEWS file at
  /usr/share/doc/gnupg/NEWS.gz for more information about fully
  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

fanquake · 2021-08-16T03:33:43Z

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.

contrib/builder-keys/README.md

maflcko · 2021-08-16T07:49:02Z

Approach ACK b4f1f998236ab1ae44a1a3c8ae84213474cae4dc, but the exe should be removed

fanquake · 2021-08-16T07:52:24Z

but the exe should be removed

Done. Not sure how I didn't notice that. Fixed the commit message typo as well.

maflcko · 2021-08-16T07:52:43Z

cr ACK a3e4ff63e3e5bd5fb46f872c59d3ca74f81c56fa

laanwj · 2021-08-16T12:33:31Z

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.

laanwj · 2021-08-16T12:38:54Z

FWIW, there's another mention of keyserver in contrib/verify-commits/README.md. Maybe replace this one too?

Zero-1729 · 2021-08-16T13:20:26Z

Yeah, I think 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.

fanquake · 2021-08-17T01:00:57Z

FWIW, there's another mention of keyserver in contrib/verify-commits/README.md. Maybe replace this one too?

Thanks. Have replaced that as well.

maflcko · 2021-08-17T06:16:21Z

cr ACK 4c43b7d

Zero-1729

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

fanquake · 2021-08-17T08:07:43Z

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

This is in line with 4c43b7d from PR #22688.

…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

fanquake added the Scripts and tools label Aug 12, 2021

fanquake force-pushed the use_ubuntu_keyserver branch from 641155a to b4f1f99 Compare August 16, 2021 03:31

fanquake changed the title ~~contrb: use keyserver.ubuntu.com to retrieve builder keys~~ contrb: use keys.openpgp.org to retrieve builder keys Aug 16, 2021

maflcko reviewed Aug 16, 2021

View reviewed changes

contrib/builder-keys/README.md Outdated Show resolved Hide resolved

maflcko changed the title ~~contrb: use keys.openpgp.org to retrieve builder keys~~ contrib: use keys.openpgp.org to retrieve builder keys Aug 16, 2021

fanquake force-pushed the use_ubuntu_keyserver branch from b4f1f99 to a3e4ff6 Compare August 16, 2021 07:51

fanquake force-pushed the use_ubuntu_keyserver branch from a3e4ff6 to 4c43b7d Compare August 17, 2021 01:00

bitcoin deleted a comment from 04487 Aug 17, 2021

Zero-1729 reviewed Aug 17, 2021

View reviewed changes

fanquake closed this Aug 17, 2021

fanquake deleted the use_ubuntu_keyserver branch August 17, 2021 08:07

real-or-random mentioned this pull request Nov 8, 2021

doc: Suggest keys.openpgp.org as keyserver in SECURITY.md #23466

Closed

fanquake pushed a commit that referenced this pull request Nov 8, 2021

doc: Suggest keys.openpgp.org as keyserver in SECURITY.md

90f1f84

This is in line with 4c43b7d from PR #22688.

bitcoin locked as resolved and limited conversation to collaborators Aug 18, 2022

Conversation

fanquake commented Aug 12, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hebasto commented Aug 12, 2021

Uh oh!

Zero-1729 commented Aug 12, 2021

Uh oh!

Zero-1729 commented Aug 12, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jamesob commented Aug 12, 2021

Uh oh!

dongcarl commented Aug 13, 2021 • edited by fanquake Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fanquake commented Aug 16, 2021

Uh oh!

Uh oh!

maflcko commented Aug 16, 2021

Uh oh!

fanquake commented Aug 16, 2021

Uh oh!

maflcko commented Aug 16, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laanwj commented Aug 16, 2021

Uh oh!

laanwj commented Aug 16, 2021

Uh oh!

Zero-1729 commented Aug 16, 2021 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fanquake commented Aug 17, 2021

Uh oh!

maflcko commented Aug 17, 2021

Uh oh!

Zero-1729 left a comment

Choose a reason for hiding this comment

Uh oh!

fanquake commented Aug 17, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

fanquake commented Aug 12, 2021 •

edited

Loading

Zero-1729 commented Aug 12, 2021 •

edited

Loading

dongcarl commented Aug 13, 2021 •

edited by fanquake

Loading

maflcko commented Aug 16, 2021 •

edited

Loading

Zero-1729 commented Aug 16, 2021 •

edited

Loading