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
Preventing Cache Races
CI/CD

Preventing Cache Races

When two tasks have the same cache key, RWX will prevent cache races.

Jul 2, 2025
Read now
Mint is Now RWX
CI/CD

Mint is Now RWX

Given the impact of our CI/CD platform, we've decided to deprecate the Mint name, and rebrand the CI/CD functionality directly as RWX.

Jul 1, 2025
Read now
More CPU and Memory for Tasks
CI/CD

More CPU and Memory for Tasks

RWX now supports running tasks with up to 64 CPUs and 256 GB of memory.

Sep 24, 2024
Read now