Saveguards for keyid mismatch

[MikeMcC399]

• Issue Newly published versions of package managers distributed from npm cannot be installed due to key id mismatch #612 records a disruption to the corepack service after npm registry keys were updated.

• Please don't make error of fetching latest version information if packageManager field is specified. #625 describes how a project with an existing packageManager record can be affected if a new package manager version is released, signed with a new key, and not used in the project.

• How can this be prevented in future? I'm not familiar with how the keys and systems for using them work, so this is a question for the experts.

---

In #612 (comment) @wraithgar wrote

https://registry.npmjs.org/-/npm/v1/keys should now be returning two keys. During key rotation the old one was omitted by mistake and has since been re-added.

Even if a mistake hadn't been made, would there still have been an issue needing keys urgently updating in Corepack?

Does Corepack need to know in advanced if npm registry keys on the endpoint https://registry.npmjs.org/-/npm/v1/keys (see https://docs.npmjs.com/about-registry-signatures) are going to be changed?

If npm registry keys are changed, is there any advanced notice from the npm registry of a plan to change?

Is there any notification that npm registry keys have changed, at the time of change or does the endpoint need to be polled by Corepack regularly?

Can Corepack ensure that the version bundled in Node.js will always have a set of keys which can be used without error?

---

Also: the more fundamental question of whether Corepack should have a copy of the npm registry keys with the risk of them becoming out of date? Could Corepack simply use the live keys on https://registry.npmjs.org/-/npm/v1/keys instead of keeping a copy in the repo?

[wraithgar]

If npm registry keys are changed, is there any advanced notice from the npm registry of a plan to change?

There shouldn't be. The values of the keys aren't something corepack needs to know beforehand. If a local reference is needed they can be cached. The response has http caching headers that should inform clients how long to cache.

expires is simply used to denote the latest date that a published package should have been signed by a given key.
keyid is the id used to correspond a package's signature with a key for signature verification. Both are present in registry results, based on when the package was published.

cf how npm correlates keyid and validates expires, and how corepack correlates keyid (it does not appear that corepack validates the expires attribute of a key)

$ npm view tailwindcss dist.signatures
{
  sig: 'MEUCIQCxnGQkT4CGZFjUwh22KPbzju3jG5+gjSTF1Y9kex1mbQIgUfmmePbMOC0Iv7GsQRPM3a+2Q8Jv5JqgYj4dKc9pDW8=',
  keyid: 'SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U'
}
$ npm view npm dist.signatures
{
  sig: 'MEYCIQCdbIJJFvhCU6D3kO7inpSRAXC930c2CLz8JqtNeP5D+QIhAJBhj+7nJMlGtsx1MqETvG5+h6TMc5ZiUo0/MUtjHm3e',
  keyid: 'SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA'
}

The endpoint has always returned an array in anticipation of key rotation. Old keys will remain in the returned data set for as long as there are artifacts in the registry that are signed by those keys.

Trying to keep the contents of that endpoint in the source code in a way that's decoupled from the source (i.e. not an http response cache) seems like it's guaranteed to have problems when those contents change. The current setup also prevents other registries from being used, as it appears to be indexed by package name, not by registry hostname.

[MikeMcC399]

@wraithgar

Thank you so much for the details and explanation!

I realized that I can answer one of the questions myself.

Even if a mistake hadn't been made, would there still have been an issue needing keys urgently updating in Corepack?

The answer is yes, there is still an issue!

pnpm@10.0.0 was signed with the older key (which expired earlier today 2025-01-29T00:00:00.000Z, meaning it shouldn't get used for signing any new packages)

$ npm view pnpm@10.0.0 dist.signatures
{
  sig: 'MEUCIBhQnfDt9V8tw3FnrqHdMokyqJJtYX7HhR5NxvfggwP/AiEAiQQ74inA/JVI5IHN0piTLb2LhSUPJAkYYsGgM8DTrCI=',
  keyid: 'SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA'
}

pnpm@10.1.0 was signed with the new key. I assume that currently any future pnpm or Yarn releases will be using this key until it itself is rotated and set to expire.

$ npm view pnpm@10.1.0 dist.signatures
{
  sig: 'MEUCIQDlkgmNyZjT7KUY8AO6jH7Gs3fyiXG8nbTnuLbd8fOS2AIgXyJ6SaYhumMFzUYQAZPJGhsnlaD5N0X2MZsbG+eS/Xo=',
  keyid: 'SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U'
}

Even though the https://registry.npmjs.org/-/npm/v1/keys has been corrected, the latest version of Corepack ( 0.30.0 ) distributed with Node.js fails to be able to install pnpm@10.1.0.

The workarounds are to set the environment variable COREPACK_INTEGRITY_KEYS=0, to manually update to corepack@0.31.0 or to install it using knowledge of the release's hash.

Any other pnpm or Yarn package published to the npm registry from today onwards is going to potentially hit this key mismatch issue.

If I have understood this correctly it would mean that Corepack would need to be enhanced to always use the live keys on https://registry.npmjs.org/-/npm/v1/keys and not use its own stored keys which could become out of date.

[wraithgar]

If I have understood this correctly it would mean that Corepack would need to be enhanced to always use the live keys on https://registry.npmjs.org/-/npm/v1/keys and not use its own stored keys which could become out of date.

This would be my recommendation. I am not a corepack maintainer though, so it's not my decision.

[aduh95]

Wouldn't making a HTTP call defeat the purpose of the signature verification? If the purpose of the signature is to have a safeguard in case someone makes a MitM attack on the registry, relying on the registry to get the keys would defeat that purpose. I'm not sure we can avoid shipping a list of trusted keys.

[MikeMcC399]

@wraithgar

Are you able to predict how often keys in https://registry.npmjs.org/-/npm/v1/keys are likely to be rotated and therefore what the risk of Corepack breaking again would be if Corepack does not address this issue?

[MikeMcC399]

• npm is also impacted by this issue. See [BUG] Unable to install 11.1.0 with corepack npm/cli#8075

[MikeMcC399]

Looking back in the history, for instance of npm releases, the earliest release shown on https://www.npmjs.com/package/npm is https://www.npmjs.com/package/npm/v/1.1.25 published 12 years ago.

$ npm view npm@1.1 dist.signatures.keyid
npm@1.1.25 'SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA'
npm@1.1.70 'SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA'
npm@1.1.71 'SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA'

The same key jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA was used all these years until npm@11.1.0 was published on Jan 29, 2025:

$ npm view npm@11 dist.signatures.keyid
npm@11.0.0 'SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA'
npm@11.1.0 'SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U'

If the signing keys on https://registry.npmjs.org/-/npm/v1/keys in future are only going to be rotated every 12 years, then this issue does not represent a practical risk for Corepack users.

If on the other hand there is a new process to rotate the keys more often, then this could represent a risk for Corepack users experiencing a time window where new keys have not propagated through a new Corepack release and distribution. During this time packages signed with a new key would fail unless additional steps are taken by users to disable integrity checks or add a hash in corepack commands.

[LucienLeMagicien]

Wouldn't making a HTTP call defeat the purpose of the signature verification? If the purpose of the signature is to have a safeguard in case someone makes a MitM attack on the registry, relying on the registry to get the keys would defeat that purpos. I'm not sure we can avoid shipping a list of trusted keys.

(EDIT: some of this is wrong, see messages below!)
I am not a security professional. However, I am not sure this attack vector (an attacker manages to MitM/impersonate registry.npmjs.org) is relevant in this situation because:

• The documentation says that this is specifically geared against malicious proxies or mirrors doing MitM. It dosn't say that it is geared against a direct HTTPS MitM on the registry, or a malicious registry.
  (To a lesser extent, I think it is also geared against local cache poisoning. This is for example relevant when using Yarn zero-install: you have to trust that whoever can write to your repo isn't uploading bad packages, or validate it in CI. See the v3 doc and yarn v4's hardened mode.)
• This signature verification mechanism has no way of knowing whether or not the keys are "trusted", outside of the facts that they come from registry.npmjs.org and trusting TLS.
  (Compare with TLS certs or Debian/Arch/RedHat packages: they have a "chain of trust" or "root of trust" where a trust anchor has signed these keys. The local package manager can verify that new keys are trusted (signed) by a key it already trusts.)
• If someone manages to MitM between you and the registry over HTTPS, you have bigger problems:
  • It means they managed to somehow trick your system/your CI into trusting a malicious cert (malicious root CA, TLS downgrade attack, ...)
  • Even if the keys were pinned so that Corepack wasn't fetching them via HTTPS, since the attacker controls what you receive they could simply send you data for another package entirely: by simply uploading a malicious package to NPM, they can get a package with a valid signature that Corepack would accept. The only way to guard against this would be to instead pin the hash of each package version.
  • Even if you pin the hash yourself (like how @MikeMcC399 explained here: Newly published versions of package managers distributed from npm cannot be installed due to key id mismatch #612 (comment)) so that you are sure that the package you receive is a trusted one, I think npm itself (and I assume other package managers) does not pin the registry's keys and would trust what it gets over HTTPS and the attack would go through.
    Trying to have Corepack act as a bonus rogue-key-detector doesn't make sense to me.
• If someone manages to hack into registry.npmjs.org, we have bigger problems.

TLDR: (I believe that) these signatures only guarantee integrity, and not authenticity.
This is instead where projects like TUF and Sigstore fit:

• https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/
• https://docs.npmjs.com/generating-provenance-statements

For reference, NPM loads keys from Sigstore then falls back to the /-/npm/v1/keys endpoint here:
https://github.com/npm/cli/blob/593c84921b0df963cef2ca7b13e44acc20cbd558/lib/utils/verify-signatures.js#L174
(Note that I don't know how to use TUF / Sigstore but I believe this is the relevant part. I also haven't looked into how other package managers get their keys.)

---

Given this, it makes sense to me that Corepack would retrieve the keys via HTTPS to verify download integrity. I believe that Sigstore is what you're looking for if you want to make sure that the package managers that Corepack downloads are the ones released by a trusted source.
Again though, I am not a security professional so hopefully someone more apt can chip in.

If you still want to pin the npm registry's integrity keys, then I think:

• This project should have a scheduled job to see if the endpoint returns a new key and notify a human. The job should at least run weekly, given the endpoint's cache headers.
• If this error happen again, Corepack should query the endpoint anyway to see if there is a new key and prompt the user to pass a flag to trust the new keys if one matches, and/or instruct them on how to set the hash for their package manager in their package.json (I believe this is what this issue is for Expand packageManager description with allowed & recommended hash values #620).

[aduh95]

• Even if the keys were pinned so that Corepack wasn't fetching them via HTTPS, since the attacker controls what you receive they could simply send you data for another package entirely: by simply uploading a malicious package to NPM, they can get a package with a valid signature that Corepack would accept. The only way to guard against this would be to instead pin the hash of each package version.

I don't think that's true, what is signed is the concatenation of ${packageName}@${version}:${integrity}, so it would only work if the package name and version matches.

• If someone manages to hack into registry.npmjs.org, we have bigger problems.

So, let's not put any safeguards? I really don't follow the logic here

TLDR: (I believe that) these signatures only guarantee integrity, and not authenticity.

The registry exposes both dist.integrity (and dist.shasum) to validate the integrity, and dist.signatures to validate the authenticity.