GeezerVison

@yosifkit @tianon I think one of you had previously flagged some issues with switching to keyrings for the official images, or did I misremember that?

@yosifkit @tianon I think one of you had previously flagged some issues with switching to keyrings for the official images, or did I misremember that?

I think you might be referring to #1509 (comment)

Maybe there is a way in the middle, where the script grabs and parses the keyring, but the image keeps the valid/current keys embedded in the Dockerfile we send upstream

I think you might be referring to #1509 (comment)

That's the one that's most directly pertinent to docker-node -- see also nodejs/node#58979 (comment), nodejs/node#58904 (comment), nodejs/node#39227 (comment) 😅

I think you might be referring to #1509 (comment)

That's the one that's most directly pertinent to docker-node -- see also nodejs/node#58979 (comment), nodejs/node#58904 (comment), nodejs/node#39227 (comment) 😅

To quote nodejs/node#58979 (comment):

"Just trust this precompiled binary bundle of key data" is not exactly something that fills me with warm fuzzies 😅 -- how would I, as a user, verify the contents of pubring.kbx? How would I know which parts of it are relevant for a given Node.js release?

And nodejs/node#39227 (comment):

IMO, https://github.com/nodejs/release-keys would be a very interesting place to include a bit more (programmatically accessible such as symlinks in folders or a JSON doc) metadata about how the keys related to releases, such as which are expected to be actively signing new releases of each version track vs which keys have been used historically to sign releases for each track and aren't expected to sign new releases (instead of just a big bundle of keys for everyone both past and present).

Having that sort of metadata/organization would make something like #1511 much easier to implement, but would also generally reduce the possibility of something like an outdated key being compromised creating a worry for new releases. 👀

As it stands, https://github.com/nodejs/release-keys is functionally not much different from the KEYS files that are common in Apache projects, albeit with some added scaffolding to help ease consumption. 😅

See also https://github.com/docker-library/faq#how-can-i-use-a-keys-file-for-verifying-pgp-signatures

Is there any unadressed objections? If I don't hear any, I plan to land this before 26.0.0 is released

Should I bother to fix conflicts here? FWIW I still think this is valuable and an improvement over the status quo, and that I have addressed all the concern that was raised, but if it's not going to land, so be it and let's close the PR.

Automating the key updates would replace a manual process and save effort in that sense. So that would be a benefit. In practice, the keys don't change very often, so the current manual effort is minimal though.

To clarify this is not a goal, not only the effort is minimal, keeping manual steps helps catch mistakes and mischiefs.

I suggest to close this PR.

update-keys.sh now pulls from https://github.com/nodejs/release-keys/raw/refs/heads/main/gpg-only-active-keys/pubring.kbx

It's not possible to remove the dependency on keyservers hkps://keys.openpgp.org & keyserver.ubuntu.com

Short-term the keyervers are needed for Yarn v1 Classic installation. That need continues until Node.js 24 EOL on 2028-04-30. After that date the lowest active release is Node.js 26 and that does not bundle Yarn v1.

Long-term there is no agreement from the Docker representatives in the team. They want the signer key in the Docker file, and the check to run through the keyservers.

They want the signer key in the Docker file, and the check to run through the keyservers.

That seems like conjecture, unless I've missed a communication from their end they haven't commented on this implementation.

Short-term the keyervers are needed for Yarn v1 Classic installation.

This is IMO off-topic since we obviously have no control over Yarn verification methods. My concern is with verifying Node.js releases with a method the project has no control over.

https://github.com/docker-library/official-images#security was the reference document.

https://github.com/docker-library/official-images#security was the reference document.

In https://github.com/docker-library/faq/#how-can-i-use-a-keys-file-for-verifying-pgp-signatures, they give an example of exactly what I'm trying to achieve

Could you explain again the need for this PR? You said you see a problem because the Node.js organization does not control the key servers. What aspect of lack of control concerns you? Is it availability of the servers? The risk of key servers being compromised? Or something else?

What is the impact of this PR not being merged?

At the moment we have a working solution, so I'm trying to understand what is missing.

The issue is that Node.js releases are signed with the releaser's private key, so if the releaser removes their key for those servers, it results on Node.js releases no longer being verifiable. It happen somewhat recently when I lost access to my private key, when I uploaded my new key it, the previous one was no longer trusted, and verification was failing. It's uncomfortable for the releaser, which are kinda bound forever to keep the same key, and uncomfortable for the project as the build are not reproducible.

@aduh95

Thank you for the explanation! I am beginning to understand your concerns.

The restrictions on e-mail re-use only affect hkps://keys.openpgp.org and these were already mitigated by PR #2252 from @tianon on Jul 7, 2025.

Keys from the Node.js release team are not affected because this repo only builds the latest versions of Node.js and it only uses keys from nodejs/release-keys > gpg-only-active-keys/pubring.kbx.

The repo doesn't support old releases.

Your problematic old key C0D6248439F1D5604AAFFB4021D900FFDB233756 belonging to Antoine du Hamel [email protected] that fails on hkps://keys.openpgp.org (error reading key: No public key) is not used here in the active main branch since it does not belong to the gpg-only-active-keys set.

As an additional example of how the mitigation currently works for the only non-Node.js key in use: the key 6A010C5166006599AA17F08146C2130DFD2497F5 belonging to [email protected] used to sign Yarn v1 fails on hkps://keys.openpgp.org (gpg: error reading key: No public key) and it automatically fails over to keyserver.ubuntu.com using the implemented mitigation.