A Node.js Maintainer Lost Their Keys

CI/CD
Jul 3, 2025
Dan Manges
A Node.js Maintainer Lost Their Keys

On Monday, a Node.js maintainer lost their keys that they used to sign a publicly available Node.js release, as reported in nodejs/node#58877.

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

This is one of those situations that leads to random things spontaneously breaking across the internet, such as Cypress docker images no longer building.

For engineering teams running their CI/CD pipelines on RWX though, everything was fine.

What are Signing Keys

Signing improves the security of downloading files from the internet.

To sign a file, a person has a private key and a public key. They use their private key to generate a signature of the file contents. Their public key is published publicly, and other people can use it to make sure the signature is legitimate. As long as the private key does not become compromised, people can be sure that the file they are downloading was provided by the intended person.

Node.js provides the public keys for people who are authorized to release new Node.js binaries. Obviously the Node runtime is highly sensitive, as a compromised binary could lead to a large number of systems being compromised.

What Happened

Technically, it was not a problem that the key was lost.

The problem happened because the maintainer published a new key on OpenPGP, which then disassociated the old key from their identity.

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.

This broke the recommended way to download keys when installing Node.

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

When running this, gpg would display gpg: key 21D900FFDB233756: no user ID and then exit successfully.

More details are available in nodejs/node#58904 and nodejs/node#58877

Why RWX was Unaffected

When installing Node.js on RWX via the nodejs/install package, we verify the signature.

However, for all of our customers, the Node.js installation was already cached. Given the following task definition:

1
tasks:
2
- key: node
3
call: nodejs/install 1.1.7
4
with:
5
node-version: "22.17.0"

The task will always be a cache hit unless node-version changes.

The benefits of caching are usually centered around faster builds and lower costs, but caching also improves reliability. In the case of an external resource breaking, builds will not be impacted as long as they're getting cache hits.

Never miss an update

Get the latest releases and news about RWX and our ecosystem with our newsletter.

Share this post

Enjoyed this post? Pleas share it on your favorite social network!

Related posts

Read more on updates and advice from the RWX engineering team

See all posts
Fast File Tree Navigation, Powered by WebAssembly
CI/CD

Fast File Tree Navigation, Powered by WebAssembly

We shipped a web-based file tree navigator to see files from a task's output. To make browsing as fast as possible, we implemented it in WebAssembly.

Jul 11, 2025
Read now
Instantly Starting Batch Downloads
CI/CD

Instantly Starting Batch Downloads

We started to build an asynchronous user experience commonly used for batch downloads. RWX is a platform built on performance though, so we made it faster.

Jul 10, 2025
Read now
Which Version of Node.js Does VS Code Use to Run Extensions?
CI/CD

Which Version of Node.js Does VS Code Use to Run Extensions?

When we built our language server and VS Code extension we wanted to determine the version of Node.js that VS Code uses to run extensions.

Jul 9, 2025
Read now