doc: update release key for aduh95

[aduh95]

I lost access to the other key, so had to generate a new one

[LiviaMedeiros]

LGTM.
The key has two user IDs associated (the other one is with rosa be email), I assume it was intentional?

[ruant]

@aduh95 Please also update the nodejs/release-keys repo as well since that's now outdated.

[MikeMcC399]

Please process this PR urgently as multiple users are reporting issues with Cypress Docker image builds that include Node.js releases signed with

Antoine du Hamel [email protected] C0D6248439F1D5604AAFFB4021D900FFDB233756

See cypress-io/cypress-docker-images#1375

[aduh95]

@MikeMcC399 this PR won't fix the issue you linked, the problem seems to be that getting the key the release was signed with from OpenPGP.org no longer works – this PR is not going to change past releases signatures, it's only going to list the new key I intend to sign future releases with.

@nodejs/releasers maybe we should not list openpgp.org as the recommended way to get releasers keys.

[MikeMcC399]

@aduh95

this PR won't fix the issue you linked, the problem seems to be that getting the key the release was signed with from OpenPGP.org no longer works – this PR is not going to change past releases signatures, it's only going to list the new key I intend to sign future releases with.

You are right!

Do we need to change to using hkps://keyserver.ubuntu.com instead as one user suggested?

[richardlau]

@nodejs/releasers maybe we should not list openpgp.org as the recommended way to get releasers keys.

Is there a particular issue with it? I've just gone through submitting my updated gpg key (with additional UID) in the following keyservers:

• keys.openpgp.org (the one listed in the main Node.js README)
• keyserver.ubuntu.com
• pgp.mit.edu

and was able to retrieve my key using the newly added email address. The one bit of uncertainty I had was the last one, pgp.mit.edu, where it wasn't clear if the update was accepted, but I was able to retrieve the key with my new email address from my updated key.

[aduh95]

Is there a particular issue with it?

Apparently. It looks like that OpenPGP won't let users download my old key – which sorta makes sense, if someone sends me a message encrypted with that old key, I won't be able to decrypt it anymore; however it's a problem when it comes to verify the releases that key has signed.

Also, IMO it's not ideal that the project has no control over it, so if either OpenPGP or the releaser (or former releaser even) changes something, it can break the project (or its users) without any possibility to fix it.

Our recommendation should probably be to get it from https://github.com/nodejs/release-keys/blob/main/keys/C0D6248439F1D5604AAFFB4021D900FFDB233756.asc, which we have more control over.

[richardlau]

Also, IMO it's not ideal that the project has no control over it, so if either OpenPGP or the releaser (or former releaser even) changes something, it can break the project (or its users) without any possibility to fix it.

Our recommendation should probably be to get it from https://github.com/nodejs/release-keys/blob/main/keys/C0D6248439F1D5604AAFFB4021D900FFDB233756.asc, which we have more control over.

Right, I guess my question was more if there was anything different about one keyserver over any other. I think I'd be +1 for making the release-keys repository the source of truth. There's probably a lot of stuff out there assuming the keys are on public keyservers, e.g.

• https://github.com/nodejs/docker-node/blob/89b29ef06b421598ec007605a2604ede0348b298/Dockerfile-debian.template#L22-L27
• https://github.com/nodejs/unofficial-builds/blob/780d680f818474198722a8c68f41a96cac1c5f6e/fetch-source/run.sh#L34-L38

[LiviaMedeiros]

FWIW OpenPGP still provides a key with old fingerprint,

$ curl -s https://keys.openpgp.org/vks/v1/by-fingerprint/C0D6248439F1D5604AAFFB4021D900FFDB233756 | pgpdump
New: Public Key Packet(tag 6)(525 bytes)
        Ver 4 - new
        Public key creation time - Wed Jan 26 00:19:54 +08 2022
        Pub alg - RSA Encrypt or Sign(pub 1)
        RSA n(4096 bits) - ...
        RSA e(17 bits) - ...
New: Public Subkey Packet(tag 14)(525 bytes)
        Ver 4 - new
        Public key creation time - Wed Jan 26 00:19:54 +08 2022
        Pub alg - RSA Encrypt or Sign(pub 1)
        RSA n(4096 bits) - ...
        RSA e(17 bits) - ...
New: Signature Packet(tag 2)(566 bytes)
        Ver 4 - new
        Sig type - Subkey Binding Signature(0x18).
        Pub alg - RSA Encrypt or Sign(pub 1)
        Hash alg - SHA256(hash 8)
        Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
         v4 -   Fingerprint - c0 d6 24 84 39 f1 d5 60 4a af fb 40 21 d9 00 ff db 23 37 56
        Hashed Sub: signature creation time(sub 2)(4 bytes)
                Time - Wed Jan 26 00:19:54 +08 2022
        Hashed Sub: key flags(sub 27)(1 bytes)
                Flag - This key may be used to encrypt communications
                Flag - This key may be used to encrypt storage
        Sub: issuer key ID(sub 16)(8 bytes)
                Key ID - 0x21D900FFDB233756
        Hash left 2 bytes - be 82
        RSA m^d mod n(4095 bits) - ...
                -> PKCS-1

but it looks like it removed the newer subkey that was associated with the email and kept a heavily outdated key that didn't have user id packets there?

Another possible option is an own keyserver, so people still can use gpg --recv-keys.

[richardlau]

FWIW OpenPGP still provides a key with old fingerprint,
but it looks like it removed the newer subkey that was associated with the email and kept a heavily outdated key that didn't have user id packets there?

My question is, did OpenPGP drop something, or has it always had an outdated version of the key? What if we uploaded the key from the release-keys repository to the keyserver?

[richardlau]

(Also I think these conversations are derailing this PR.)

[LiviaMedeiros]

If the private part of the key is lost as in "nobody has and ever will have access to it" and not as in "there is a slightest chance of key being compromised", it would make sense to re-upload the public part to openpgp, so past releases can be verified without users having to change the source or retrieval method.
If it conflicts with the newer key's user ID, there's still an option of dropping the "old" email from new key, although it probably would be at least less convenient to use.

[MikeMcC399]

If the private part of the key is lost as in "nobody has and ever will have access to it" and not as in "there is a slightest chance of key being compromised", it would make sense to re-upload the public part to openpgp, so past releases can be verified without users having to change the source or retrieval method. If it conflicts with the newer key's user ID, there's still an option of dropping the "old" email from new key, although it probably would be at least less convenient to use.

Could we make this a separate issue (EDIT: that's #58904) for dealing with the following on hkps://keys.openpgp.org:

Antoine du Hamel [email protected] C0D6248439F1D5604AAFFB4021D900FFDB233756

I would gladly open a new issue myself, however I'm currently traveling, so I probably wouldn't be able to do this until tomorrow.

[MikeMcC399]

@aduh95

Your new key 5BE8A3F6C8A5C01D106C0AD820B1A390B168D356 isn't available on keyserver.ubuntu.com. Is that intentional?

$ gpg --batch --keyserver keyserver.ubuntu.com --recv-keys 5BE8A3F6C8A5C01D106C0AD820B1A390B168D356
gpg --list-sigs 5BE8A3F6C8A5C01D106C0AD820B1A390B168D356
gpg: keyserver receive failed: No data
gpg: error reading key: No public key

This would be the only key in the README section Release keys "Primary GPG keys for Node.js Releasers" that is not available from keyserver.ubuntu.com.

[MikeMcC399]

@aduh95

It's an unusual situation to have a problem with a key that has been used to sign the latest Active LTS version, currently Node.js 22.17.0

So I suggest, instead of removing

gpg --keyserver hkps://keys.openpgp.org --recv-keys C0D6248439F1D5604AAFFB4021D900FFDB233756 # Antoine du Hamel

from the Primary PGP Release keys list right now, change it to

gpg --keyserver keyserver.ubuntu.com --recv-keys C0D6248439F1D5604AAFFB4021D900FFDB233756 # Antoine du Hamel

in a separate intermediate PR that could be merged without delay. This would then restore the list https://github.com/nodejs/node/blob/main/README.md#release-keys with the heading "To import the full set of trusted release keys (including subkeys possibly used to sign releases)" to be a working set of instructions.

The new key could be added later and separately.