Newly published versions of package managers distributed from npm cannot be installed due to key id mismatch

This is probably related to #611.

When I try to install pnpm 10.1.0, I get the following error:

C:\Program Files\nodejs\node_modules\corepack\dist\lib\corepack.cjs:21535
  if (key == null || signature == null) throw new Error(`Cannot find matching keyid: ${JSON.stringify({ signatures, keys })}`);
                                              ^

Error: Cannot find matching keyid: {"signatures":[{"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","sig":"MEUCIQDlkgmNyZjT7KUY8AO6jH7Gs3fyiXG8nbTnuLbd8fOS2AIgXyJ6SaYhumMFzUYQAZPJGhsnlaD5N0X2MZsbG+eS/Xo="}],"keys":[{"expires":null,"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","keytype":"ecdsa-sha2-nistp256","scheme":"ecdsa-sha2-nistp256","key":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1Olb3zMAFFxXKHiIkQO5cJ3Yhl5i6UPp+IhuteBJbuHcA5UogKo0EWtlWwW6KSaKoTNEYL7JlCQiVnkhBktUgg=="}]}
    at verifySignature (C:\Program Files\nodejs\node_modules\corepack\dist\lib\corepack.cjs:21535:47)
    at installVersion (C:\Program Files\nodejs\node_modules\corepack\dist\lib\corepack.cjs:21882:7)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async Engine.ensurePackageManager (C:\Program Files\nodejs\node_modules\corepack\dist\lib\corepack.cjs:22316:32)
    at async Engine.executePackageManagerRequest (C:\Program Files\nodejs\node_modules\corepack\dist\lib\corepack.cjs:22416:25)
    at async Object.runMain (C:\Program Files\nodejs\node_modules\corepack\dist\lib\corepack.cjs:23102:5)        

Node.js v22.13.0

I checked https://registry.npmjs.org/pnpm/10.1.0 and it contains

{
  "signatures": [
    {
      "keyid": "SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U",
      "sig": "MEUCIQDlkgmNyZjT7KUY8AO6jH7Gs3fyiXG8nbTnuLbd8fOS2AIgXyJ6SaYhumMFzUYQAZPJGhsnlaD5N0X2MZsbG+eS/Xo="
    }
  ]
}

which has the same key id distributed at https://registry.npmjs.org/-/npm/v1/keys.
On the other hand, pnpm@10.0.0 (https://registry.npmjs.org/pnpm/10.0.0) has:

{
  "signatures": [
    {
      "sig": "MEUCIBhQnfDt9V8tw3FnrqHdMokyqJJtYX7HhR5NxvfggwP/AiEAiQQ74inA/JVI5IHN0piTLb2LhSUPJAkYYsGgM8DTrCI=",
      "keyid": "SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA"
    }
  ]
}

which has the same key id in config.json.

corepack/config.json

Line 169 in 9dfbe18

"keyid": "SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA",

@sapphi-red

@sapphi-red

I can reproduce this issue on Windows 11 and Ubuntu 24.04.1 LTS with

corepack use pnpm@10.1.0

Cannot find matching keyid

corepack use pnpm@10.0.0

has no issue, so you might change your subject to be specifically 10.1.0 instead of the generic "Newly published versions".

Also, this should probably be reported to https://github.com/pnpm/pnpm/issues
cc: @zkochan

I can confirm that the same issue happens for us as well in our GitLab Pipeline:

$ corepack enable && corepack prepare --activate
Preparing pnpm@10.1.0 for immediate activation...
Internal Error: Cannot find matching keyid: {"signatures":[{"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","sig":"MEUCIQDlkgmNyZjT7KUY8AO6jH7Gs3fyiXG8nbTnuLbd8fOS2AIgXyJ6SaYhumMFzUYQAZPJGhsnlaD5N0X2MZsbG+eS/Xo="}],"keys":[{"expires":null,"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","keytype":"ecdsa-sha2-nistp256","scheme":"ecdsa-sha2-nistp256","key":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1Olb3zMAFFxXKHiIkQO5cJ3Yhl5i6UPp+IhuteBJbuHcA5UogKo0EWtlWwW6KSaKoTNEYL7JlCQiVnkhBktUgg=="}]}
    at verifySignature (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:21535:47)
    at installVersion (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:21882:7)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async Engine.ensurePackageManager (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:22316:32)
    at async PrepareCommand.execute (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:23025:27)
    at async PrepareCommand.validateAndExecute (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:19835:22)
    at async _Cli.run (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:20772:18)
    at async Object.runMain (/usr/lib/node_modules/corepack/dist/lib/corepack.cjs:23097:19)

I assume the signatures are generated by npm registry and pnpm has no control over it. I'll change the issue name to specifically 10.1.0, but I believe any versions that are published from now on will be affected, as I think it's caused by npm registry's key rotation.
I wonder if the npm registry had to rotate the key immediately (and not in a gradual manner) due to some vulnerability discovery.

For those who are facing this issue like me, you can add COREPACK_INTEGRITY_KEYS=0 env var to skip the signature check.

We're pinned to 9.15.4 and seeing this on CI, so it's not limited to 10.1.0

For those who are facing this issue like me, you can add COREPACK_INTEGRITY_KEYS=0 env var to skip the signature check.

Whilst this may work around the issue and is tempting, if there is an undisclosed vulnerability behind all of this as you speculate, then ignoring the key integrity might result in running evil code.

@sapphi-red

@sapphi-red

I assume the signatures are generated by npm registry and pnpm has no control over it. I'll change the issue name to specifically 10.1.0, but I believe any versions that are published from now on will be affected, as I think it's caused by npm registry's key rotation. I wonder if the npm registry had to rotate the key immediately (and not in a gradual manner) due to some vulnerability discovery.

The endpoint https://registry.npmjs.org/-/npm/v1/keys (mentioned for instance in the documentation https://docs.npmjs.com/about-registry-signatures) is currently returning two different keys without much discernable pattern as to which key will be returned. This is mentioned in issue config.test randomly failing in CI (key store should be up-to-date) #611. The server farm responding to https://registry.npmjs.org includes 24 different IP addresses and I guess it depends on exactly which Cloudflare server the request hits. I don't know the reason for the two different keys and probably it should be raised to https://www.npmjs.com/support for clarification / remediation.

For those who are facing this issue like me, you can add COREPACK_INTEGRITY_KEYS=0 env var to skip the signature check.

Whilst this may work around the issue and is tempting, if there is an undisclosed vulnerability behind all of this as you speculate, then ignoring the key integrity might result in running evil code.

Isn't it the opposite? If the key was rotated, the old key cannot be trusted and the new key can be trusted. The current corepack only checks the old key. To be strictly safe, you shouldn't install any packages signatured with the old key and only use packages signatured with the new key, and given that corepack does not check the signature with the new key, you need to manually check it.

I don't know the reason for the two different keys and probably it should be raised to https://www.npmjs.com/support for clarification / remediation.

I've sent a message there linking this and that issue 👍

There is now an issue reported against pnpm Installing pnpm 10.1.0 on windows fails with cannot find matching keyid pnpm/pnpm#9014

While using the latest-10 tag is not working right now, a pinned version can help to get your CI running 🐌

corepack prepare pnpm@10.0.0 --activate

Fix pnpm test

I ended up installing pnpm@10.0.0 globally (can be done with their one-liner / npm install --global pnpm@10.0.0 / mise / etc.). New v10 has manage-package-manager-versions enabled by default, which substitutes corepack. When inside a project directory, globally installed pnpm v10 checks package.json → packageManager and automatically substitutes itself with the exact version specified.

So unless you rely on corepack to manage Yarn as well, it is no longer needed. The only exception I see is CI when you can avoid two pnpm downloads with one, via corepack enable.

@BeyondEvil

Did you try changing to:

RUN npm install -g corepack@latest
RUN corepack enable && corepack prepare --activate
Sorry, I'm not familiar in-depth with the deprecated commands, but I believe that they should still work even if the local documentation has been dropped for them.

latest won't work for us as this our production build. But thanks for taking the time, really appreciate it! 🙏

We'll stick with prepare --activate until we can bump the version to v.0.31.0

@BeyondEvil

@BeyondEvil

latest won't work for us as this our production build.

So does that mean you can't use npm install -g corepack@0.31.0 either?

But thanks for taking the time, really appreciate it! 🙏

You're very welcome! I'm just trying to work out how to use Corepack for my own purposes and seem to have got caught up in events here!

JavaScript GitHub Actions are also impacted where Corepack is used inside an action. It's not possible to update Corepack inside the action. It needs Node.js to distribute a new version of Corepack and GitHub Actions needs to set this version corresponding to the runs.using parameter.

See "Cannot find matching keyid" if Corepack enabled cypress-io/github-action#1355 for details

While using the latest-10 tag is not working right now, a pinned version can help to get your CI running 🐌
corepack prepare pnpm@10.0.0 --activate

This worked for my Dockerfile and Node 23.6.1

RUN corepack prepare pnpm@10.0.0 --activate && corepack enable pnpm && pnpm run build

JavaScript GitHub Actions are also impacted where Corepack is used inside an action. It's not possible to update Corepack inside the action. It needs Node.js to distribute a new version of Corepack and GitHub Actions needs to set this version corresponding to the runs.using parameter.

See "Cannot find matching keyid" if Corepack enabled with new package manager cypress-io/github-action#1355 for details

And looks like Node already updated Corepack as specifying the latest Node (23.7.0) in my Docker file I'm able to run it as usual

corepack enable pnpm && pnpm run build

@esausilva

@esausilva

And looks like Node already updated Corepack as specifying the latest Node (23.7.0) in my Docker file I'm able to run it as usual
corepack enable pnpm && pnpm run build

That is correct. Node.js 23.7.0 already contains Corepack 0.31.0

The Node.js maintainers replied in Node.js LTS rollout of minimum Corepack 0.31.0? #627 (comment) that there is a policy to first test in the current version Node.js 23.x before releasing into the Node.js LTS versions. So that is not going to happen overnight.

I have tried

corepack enabled && corepack prepare --activate

In my github actions for a job that basically install Node, npm and pnpm while I have "packageManager": "pnpm@9.12.3" in my package.json. Yet, I still get the error in my github's CI... Is there a way to explicitly target corepack 0.31.0 (the one with the key fix) without bumping to ode 23 (which is not LTS yet)

I am on Node v22.11.0

@FelixBlaisThon

@FelixBlaisThon

Is there a way to explicitly target corepack 0.31.0 (the one with the key fix) without bumping to ode 23 (which is not LTS yet)

I am on Node v22.11.0

In GitHub Actions I used the following:

      - name: Set alternate npm integrity keys
        run: |
          echo COREPACK_INTEGRITY_KEYS="$(curl https://registry.npmjs.org/-/npm/v1/keys | jq -c '{npm: .keys}')" >> $GITHUB_ENV

which works for any version of Node.js.

@BeyondEvil

latest won't work for us as this our production build.

So does that mean you can't use npm install -g corepack@0.31.0 either?

Technically that would work, but the question becomes how we keep parity between local dev, CI and Docker/production without too much maintenance.

But thanks for taking the time, really appreciate it! 🙏

You're very welcome! I'm just trying to work out how to use Corepack for my own purposes and seem to have got caught up in events here!

It happens! 😅

@MikeMcC399

@MikeMcC399

In GitHub Actions I used the following:

  - name: Set alternate npm integrity keys
    run: |
      echo COREPACK_INTEGRITY_KEYS="$(curl https://registry.npmjs.org/-/npm/v1/keys | jq -c '{npm: .keys}')" >> $GITHUB_ENV

which works for any version of Node.js.

It works! Thanks a lot! 👍

I would recommend against curl the registry keys or the shasum; though it can unblock you, you have to understand you are trusting HTTPS when doing that, and you might as well disable signature verification at this point (the signature verification is a redundant security mechanism that only makes sense to do if you are not fetching the keys via HTTPS).

Ideally the workaround would be to use latest version of Corepack. However, if that's not an option, you can either:

If you trust HTTPS, set COREPACK_INTEGRITY_KEYS to 0 to skip the signature verification. Corepack will still verifies the integrity of the download by comparing the shasum with the one found in the registry package metadata.
If you don't trust HTTPS, set COREPACK_INTEGRITY_KEYS to {"npm":[{"expires":"2025-01-29T00:00:00.000Z","keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","keytype":"ecdsa-sha2-nistp256","scheme":"ecdsa-sha2-nistp256","key":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1Olb3zMAFFxXKHiIkQO5cJ3Yhl5i6UPp+IhuteBJbuHcA5UogKo0EWtlWwW6KSaKoTNEYL7JlCQiVnkhBktUgg=="},{"expires":null,"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","keytype":"ecdsa-sha2-nistp256","scheme":"ecdsa-sha2-nistp256","key":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEY6Ya7W++7aUPzvMTrezH6Ycx3c+HOKYCcNGybJZSCJq/fd7Qa8uuAKtdIkUQtQiEKERhAmE5lMMJhP8OkDOa2g=="}]}.

npm install --global corepack@latest

Perhaps it would be good to lock this thread to contributors? Any solutions to the problem as it exists now have already been added to this thread, and further comments just add noise that serves no purpose as long as Corepack is not upgraded in actively supported versions of Node.js.

This might be a dumb question, but who screwed up here? Was this just a case of all of us not correctly configuring our CI pipelines and being vulnerable to some latent "behavior" of corepack/npm, or was something actively changed to "cause" this? I ask not to place blame, but to better understand what happened for future reference.

@tskimmett

This might be a dumb question, but who screwed up here? Was this just a case of all of us not correctly configuring our CI pipelines and being vulnerable to some latent "behavior" of corepack/npm, or was something actively changed to "cause" this? I ask not to place blame, but to better understand what happened for future reference.

There is a separate issue to address how to prevent this happening in future. See https://github.com/nodejs/corepack/issues/616

This was not caused by end-user error.

This issue was triggered by npm rotating the keys that sign packages on its registry. There was a bug in Corepack that, when no "global" version was cached, would always first download the latest one even if a specific one was defined in the package.json; when npm rotated its key and pnpm and npm released new versions soon after, Corepack started failing on CI as those environment typically do not have any cached version.
Corepack released a new version with the new key ASAP, but it takes a while for that version to propagate; the experimental status of Corepack did not help, as the Node.js project does not make emergency non-security releases for experimental features. It has since then decided that Node.js 24.x will be the last release line that distributes Corepack (i.e. as of Node.js 25.0.0, users who wish to keep using Corepack would have to install it separately, read more about this in https://socket.dev/blog/node-js-tsc-votes-to-stop-distributing-corepack).

The bug that made CI fetch a "global" version was fixed, so next time npm rotates its key, CI would not be affected as long as the project provides a specific version and a hash in the packageManager field. There's an open PR to make Corepack auto-download new keys.

Apologies to everyone who was impacted!

Navigation Menu

Repository navigation

Newly published versions of package managers distributed from npm cannot be installed due to key id mismatch #612

91 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Newly published versions of package managers distributed from npm cannot be installed due to key id mismatch #612

Description

Activity

MikeMcC399 commented on Jan 27, 2025

SenseiMarv commented on Jan 27, 2025

sapphi-red commented on Jan 27, 2025

sapphi-red commented on Jan 27, 2025

DaveEvans-Thalamos commented on Jan 27, 2025

DaveEvans-Thalamos commented on Jan 27, 2025

MikeMcC399 commented on Jan 27, 2025

sapphi-red commented on Jan 27, 2025

sapphi-red commented on Jan 27, 2025

MikeMcC399 commented on Jan 27, 2025

hmaack commented on Jan 27, 2025

kachkaev commented on Jan 27, 2025

91 remaining items

BeyondEvil commented on Feb 3, 2025

MikeMcC399 commented on Feb 3, 2025

MikeMcC399 commented on Feb 3, 2025

esausilva commented on Feb 3, 2025

MikeMcC399 commented on Feb 3, 2025

FelixBlaisThon commented on Feb 3, 2025

MikeMcC399 commented on Feb 3, 2025

BeyondEvil commented on Feb 3, 2025

Jaciezyt commented on Feb 3, 2025

aduh95 commented on Feb 3, 2025

aeharding commented on Feb 3, 2025

jonkoops commented on Feb 3, 2025

tskimmett commented on Feb 3, 2025

MikeMcC399 commented on Feb 3, 2025

aduh95 commented on Mar 23, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions