Skip to content

Not working release-key import #39114

Closed
Closed
Not working release-key import#39114
Labels
release-agendaIssues and PRs to discuss during Release team meetings.

Description

@starfish719
starfish719
opened on Jun 22, 2021
  • Version:
  • Platform:
  • Subsystem:

What steps will reproduce the bug?

Update 2021-06-21: Due to even more GDPR takedown requests, the DNS records for the pool will no longer be provided at all.
  • Update import command on readme, please. 🙏

How often does it reproduce? Is there a required condition?

What is the expected behavior?

What do you see instead?

Additional information

#9 sha256:9ae7e26adcdcc8596511b4338d2b7776f52d974d2ee5944807abf234a7a83a9f
#9 0.350 + gpg --keyserver hkp://pool.sks-keyservers.net--recv-keys 4ED778F539E3634C779C87C6D7062848A1AB005C
#9 0.355 gpg: directory '/root/.gnupg' created
#9 0.355 gpg: keybox '/root/.gnupg/pubring.kbx' created
#9 1.175 gpg: keyserver receive failed: No name

Activity

  1. targos commented on Jun 22, 2021

    @targos
    targos
    on Jun 22, 2021
    Member

    Also reported at nodejs/docker-node#1500

  2. richardlau
    added
    release-agendaIssues and PRs to discuss during Release team meetings.
    on Jun 22, 2021

  3. mmarchini commented on Aug 20, 2021

    @mmarchini
    mmarchini
    on Aug 20, 2021
    Contributor

    Should we update our README with instructions to pool from ubuntu or openpgp as suggested here?

  4. Mesteery commented on Aug 20, 2021

    @Mesteery
    Mesteery
    on Aug 20, 2021
    Contributor

    #39227

  5. duxsco commented on Aug 26, 2021

    @duxsco
    duxsco
    on Aug 26, 2021

    Nowadays, https://keys.openpgp.org is the best keyserver to use (IMHO).

    As long as the Node.js release engineers don't verify their e-mail addresses I can think of only two suitable ways to fetch the public keys from https://keys.openpgp.org:

    This means that unpatched versions of GnuPG cannot receive updates from keys.openpgp.org for keys that don't have any verified email address.

    source: https://keys.openpgp.org/about/faq#older-gnupg

    1. Approach "go via a roundabout way":
    gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 4ED778F539E3634C779C87C6D7062848A1AB005C
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 94AE36675C464D64BAFA68DD7434390BDBE9B9C5
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 74F12602B6F1C4E913FAA37AD3A89613643B6201
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 71DCFD284A79C3B38668286BC97EC7A07EDE3FC1
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys DD8F2338BAE7501E3DD5AC78C273792F7D83545D
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys A48C2BEE680E841632CD4E44F07496B3EB3C1762
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys 108F52B48DB57BB0CC439B2997B01419BD92F80A
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys B9E2F5981AA6E0CD28160D9FF13993A75599653C
gpg --keyserver hkps://keys.openpgp.org --refresh-keys

    I am doing a gpg --refresh-keys, because some public keys used to be expired at hkps://keyserver.ubuntu.com.

    1. Approach "go via API":
    curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/4ED778F539E3634C779C87C6D7062848A1AB005C | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/94AE36675C464D64BAFA68DD7434390BDBE9B9C5 | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/74F12602B6F1C4E913FAA37AD3A89613643B6201 | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/71DCFD284A79C3B38668286BC97EC7A07EDE3FC1 | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8 | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/DD8F2338BAE7501E3DD5AC78C273792F7D83545D | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/A48C2BEE680E841632CD4E44F07496B3EB3C1762 | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/108F52B48DB57BB0CC439B2997B01419BD92F80A | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/B9E2F5981AA6E0CD28160D9FF13993A75599653C | gpg --import

    🤔 Four public keys are causing problems:

    curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/71DCFD284A79C3B38668286BC97EC7A07EDE3FC1 | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/94AE36675C464D64BAFA68DD7434390BDBE9B9C5 | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/A48C2BEE680E841632CD4E44F07496B3EB3C1762 | gpg --import
curl -fsSL --tlsv1.3 --proto '=https' https://keys.openpgp.org/vks/v1/by-fingerprint/B9E2F5981AA6E0CD28160D9FF13993A75599653C | gpg --import

    ... results in:

    gpg: key 0xC97EC7A07EDE3FC1: no user ID
gpg: Total number processed: 1
gpg: key 0x7434390BDBE9B9C5: no user ID
gpg: Total number processed: 1
gpg: key 0xF07496B3EB3C1762: no user ID
gpg: Total number processed: 1
gpg: key 0xF13993A75599653C: no user ID
gpg: Total number processed: 1

  6. duxsco commented on Aug 26, 2021

    @duxsco
    duxsco
    on Aug 26, 2021

    I think the release engineers should push their public keys to https://keys.openpgp.org/ and verify their e-mail addresses. Alternatively, the Node.js project could host their own keyserver like the people from the Gentoo Linux project:
    https://www.gentoo.org/downloads/signatures/

  7. targos commented on Feb 18, 2022

    @targos
    targos
    on Feb 18, 2022
    Member

    Fixed in #39227

  8. targos
    closed this as completedon Feb 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    release-agendaIssues and PRs to discuss during Release team meetings.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions