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.