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

[sapphi-red]

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, [email protected] (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",

[MikeMcC399]

@sapphi-red

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

corepack use [email protected]

Cannot find matching keyid

---

corepack use [email protected]

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

[SenseiMarv]

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

$ corepack enable && corepack prepare --activate
Preparing [email protected] 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)

[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.

[sapphi-red]

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

[DaveEvans-Thalamos]

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

[DaveEvans-Thalamos]

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.

[MikeMcC399]

@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.

[sapphi-red]

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.

[sapphi-red]

• 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 👍

[MikeMcC399]

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

[hmaack]

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

corepack prepare [email protected] --activate

[kachkaev]

I ended up installing [email protected] globally (can be done with their one-liner / npm install --global [email protected] / 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.

[wraithgar]

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. CDN caching will of course take a little time to catch up but both the SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA key (which was used to sign tarballs up until last week) and the SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U key (which is being used going forward) are both in that endpoint, which should allow folks to verify signatures again.

[MikeMcC399]

@wraithgar

Many thanks for fixing the keys on https://registry.npmjs.org/-/npm/v1/keys ! Viewing with Postman I now see

{
    "keys": [
        {
            "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=="
        }
    ]
}

[MikeMcC399]

As mentioned by @DaveEvans-Thalamos in #612 (comment) ⬆, the keys can be ignored as a workaround, for example in a bash shell:

COREPACK_INTEGRITY_KEYS=0 corepack use [email protected]

[MikeMcC399]

@sapphi-red

There has been a new release [email protected] with updated npm keys.

After a manual install:

npm install -g corepack@latest

I was then able to execute the following successfully:

corepack use [email protected]

[rubybui]

Thank you. Add this into my workflow file works like a charm.
- name: Update Corepack to the Latest Version
shell: bash
run: npm install -g corepack@latest

PS Adding " Cannot find matching keyid: {"signatures":" corepack github action for easier search to this thread.

[EndangeredMassa]

The PR to fix this is great, but was published in a corepack version (0.31.0) that removed support for Node 21 (and presumably lower). I still need this fix for older Node versions that still have LTS support, like 18 and 20.

Can we get another version published (like 0.30.1 based on 0.30.0) that includes only they patch to keys?

[MikeMcC399]

@BeyondEvil

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

So does that mean you can't use npm install -g [email protected] 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!

[MikeMcC399]

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

[esausilva]

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

corepack prepare [email protected] --activate

This worked for my Dockerfile and Node 23.6.1

RUN corepack prepare [email protected] --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

[MikeMcC399]

@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.

[FelixBlaisThon]

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": "[email protected]" 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

[MikeMcC399]

@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]

@BeyondEvil

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

So does that mean you can't use npm install -g [email protected] 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! 😅

[Jasonzyt]

@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! 👍

[aduh95]

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=="}]}.

[aeharding]

npm install --global corepack@latest

[jonkoops]

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.

[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.

[MikeMcC399]

@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 Saveguards for keyid mismatch #616

This was not caused by end-user error.