Skip to content

Conversation

@fanquake
Copy link
Member

@fanquake fanquake commented Aug 12, 2021

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
Copy link
Member

hebasto commented Aug 12, 2021

Concept ACK.

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

@Zero-1729
Copy link
Contributor

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
Copy link
Contributor

Zero-1729 commented Aug 12, 2021

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
Copy link
Contributor

jamesob commented Aug 12, 2021

ACK 641155a

@dongcarl
Copy link
Contributor

dongcarl commented Aug 13, 2021

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 fanquake force-pushed the use_ubuntu_keyserver branch from 641155a to b4f1f99 Compare August 16, 2021 03:31
@fanquake 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
@fanquake
Copy link
Member Author

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.

@maflcko 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
@maflcko
Copy link
Member

maflcko commented Aug 16, 2021

Approach ACK b4f1f998236ab1ae44a1a3c8ae84213474cae4dc, but the exe should be removed

@fanquake fanquake force-pushed the use_ubuntu_keyserver branch from b4f1f99 to a3e4ff6 Compare August 16, 2021 07:51
@fanquake
Copy link
Member Author

but the exe should be removed

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

@maflcko
Copy link
Member

maflcko commented Aug 16, 2021

cr ACK a3e4ff63e3e5bd5fb46f872c59d3ca74f81c56fa

@laanwj
Copy link
Member

laanwj commented Aug 16, 2021

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
Copy link
Member

laanwj commented Aug 16, 2021

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

@Zero-1729
Copy link
Contributor

Zero-1729 commented Aug 16, 2021

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 fanquake force-pushed the use_ubuntu_keyserver branch from a3e4ff6 to 4c43b7d Compare August 17, 2021 01:00
@fanquake
Copy link
Member Author

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

Thanks. Have replaced that as well.

@bitcoin bitcoin deleted a comment from 04487 Aug 17, 2021
@maflcko
Copy link
Member

maflcko commented Aug 17, 2021

cr ACK 4c43b7d

Copy link
Contributor

@Zero-1729 Zero-1729 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 4c43b7d

fanquake added a commit to bitcoin-core/gui that referenced this pull request Aug 17, 2021
…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
Copy link
Member Author

This was merged in fdd80b0.

@fanquake fanquake closed this Aug 17, 2021
@fanquake fanquake deleted the use_ubuntu_keyserver branch August 17, 2021 08:07
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Aug 20, 2021
…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
fanquake pushed a commit that referenced this pull request Nov 8, 2021
fanquake added a commit that referenced this pull request Nov 8, 2021
…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
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Nov 9, 2021
…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
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Apr 3, 2022
…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
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 18, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants