Can no longer validate signatures on NodeJS binaries due to needing approval on keyserver

[the-gabe]

Version

No response

Platform

Subsystem

No response

What steps will reproduce the bug?

gpg --keyserver hkps://keys.openpgp.org --recv-keys C0D6248439F1D5604AAFFB4021D900FFDB233756 # Antoine du Hamel now fails with key 21D900FFDB233756: new key but contains no user ID - skipped

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

Always

What is the expected behavior? Why is that the expected behavior?

The key is approved on the keyserver

What do you see instead?

broken

Additional information

No response

[the-gabe]

Hey @aduh95 I guess you might be able to resolve this by doing a verification email for your signing key at openpgp.org. Thanks!

Mitigating currently by using the Ubuntu keyserver instead.

[aduh95]

Not really, it seems that OpenPGP doesn't support having two keys associated with the same email address – which makes sense if you're trying to use it to send me an encrypted message, but is unfortunate if you only want to verify my past signatures.

[the-gabe]

That's unfortunate. It would be nice to have an alternate suggested means of key obtainment documented within the README for this scenario.

[aduh95]

I definitely agree, I've suggested exactly that in #58877 (comment). I'm sorry for the inconvenience

[ruant]

A workaround that works for me at least is:

curl https://raw-githubusercontent-com-gh.computerqwq.top/nodejs/release-keys/HEAD/keys/C0D6248439F1D5604AAFFB4021D900FFDB233756.asc | gpg --import

instead of relaying on the opengpg keyserver.

Out of curiosity, why oh why doesn't the nodejs organization have it's own key that does all the signings?
It's a complete mess with all these "private" gpg keys belonging to maintainers that come and go.

[richardlau]

Out of curiosity, why oh why doesn't the nodejs organization have it's own key that does all the signings? It's a complete mess with all these "private" gpg keys belonging to maintainers that come and go.

Because then you have to manage access to the shared key. You'd either have to allow the private part of the key to exist on multiple machines (belonging to the releasers) or on a shared machine (whereby if it was compromised the attacker would be able to sign releases). With the current set up, the private part of the signing key is only known by the releaser it belongs to. That also gives some accountability -- I cannot sign releases with another releaser's key (or vice versa).

We've had releasers lose their laptops which meant we only needed to invalidate one key -- in the setup with a single signing key we'd need to revoke the shared key in those cases.

[ruant]

Put it as a secret here in github actions, and use a ci-pipeline here in github to build whatever needs to be built and signed?
Nobody needs the keys, we live in 2025...?

[MikeMcC399]

it seems that OpenPGP doesn't support having two keys associated with the same email address – which makes sense if you're trying to use it to send me an encrypted message, but is unfortunate if you only want to verify my past signatures.

Confirmed in the hkps://keys.openpgp.orgs FAQ Can I verify more than one key for some email address?

An email address can only be associated with a single key. When an address is verified for a new key, it will no longer appear in any key for which it was previously verified. Non-identity information will still be distributed for all keys.

@aduh95

Do you know if this also applies to keyserver.ubuntu.com? If the Ubuntu keyserver is more tolerant and would continue to allow importing the original key C0D6248439F1D5604AAFFB4021D900FFDB233756, then the following step used in https://github.com/nodejs/docker-node/blob/main/Dockerfile-debian.template could be re-ordered to prefer keyserver.ubuntu.com

Currently it's like this, and we're using this in Cypress Docker image Dockerfiles as well:

      gpg --batch --keyserver hkps://keys.openpgp.org --recv-keys "$key" || \
      gpg --batch --keyserver keyserver.ubuntu.com --recv-keys "$key" ; \

This is a problem for the Cypress Docker image build process, because they are not only built when a new Node.js is released.

If the command gpg --batch --keyserver hkps://keys.openpgp.org --recv-keys C0D6248439F1D5604AAFFB4021D900FFDB233756 is executed, a skip message is output, no key is imported, and the return code is success 0, so keyserver.ubuntu.com is never used.

Reversing the order in the above sequence, using keyserver.ubuntu.com before hkps://keys.openpgp.org appears to work. I'm not sure if there are any "gotchas" for the change, but I'm going to propose it in the Cypress Docker repo, as otherwise release of a new Cypress Docker image for the planned new Cypress release today will be blocked.

[MikeMcC399]

The following illustrates the issue that the instructions in https://github.com/nodejs/node/blob/main/README.md#release-keys fail for key C0D6248439F1D5604AAFFB4021D900FFDB233756 and that the return code is 0 (success) when an attempt is made to import the key

To import the full set of trusted release keys (including subkeys possibly used to sign releases):
gpg --keyserver hkps://keys.openpgp.org --recv-keys C0D6248439F1D5604AAFFB4021D900FFDB233756 # Antoine du Hamel

docker run -it --rm debian:12
# at bash prompt then execute ...
apt-get update && apt-get install ca-certificates gnupg -y
gpg --keyserver hkps://keys.openpgp.org --recv-keys C0D6248439F1D5604AAFFB4021D900FFDB233756 # Antoine du Hamel
echo $?
gpg --list-sigs C0D6248439F1D5604AAFFB4021D900FFDB233756

The README needs to have working instructions. Possibly Node.js should prefer using keyserver.ubuntu.com instead of hkps://keys.openpgp.org? I don't however personally have enough background on this topic to give advice. I'm just looking for reliable advice!

[MikeMcC399]

• A similar issue was reported two years ago Unable to install node 18.12.1 with the cypress/factory cypress-io/cypress-docker-images#851

From https://github.com/nodejs/node/blob/main/README.md#release-keys

Juan José Arboleda soyjuanarbol@gmail.com DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7

replaced the previous key

Juan José Arboleda soyjuanarbol@gmail.com 61FC681DFB92A079F1685E77973F295594EC4689

The key 61FC681DFB92A079F1685E77973F295594EC4689 was then no longer served from hkps://keys.openpgp.org

14:09:04  + gpg --batch --keyserver hkps://keys.openpgp.org --recv-keys 61FC681DFB92A079F1685E77973F295594EC4689
14:09:05  gpg: key 973F295594EC4689: new key but contains no user ID - skipped
14:09:05  gpg: Total number processed: 1
14:09:05  gpg:           w/o user IDs: 1

preventing verification of Node.js 18.12.1 released by Juan José Arboleda on Nov 04, 2022.

This indicates that it is a recurring problem, even though the frequency is low.