Please don't make error of fetching latest version information if packageManager field is specified.

Summary

Please don't make error hard error of resolving latest version when packageManager field is specified.

It might be good to not resolve latest version when packageManager field is specified.

Description

Many projects recently experience error Error: Cannot find matching keyid: when we call pnpm though corepack.

/opt/n/lib/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":[{"sig":"MEQCIHGqHbvc2zImUPEPFpT4grh6rMYslel+lAjFArx8+RUdAiBfnJA+bgmUvO5Lctfkq+46KKDQdx/8RhLPge3pA+EdHA==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"keys":[{"expires":null,"keyid":"SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA","keytype":"ecdsa-sha2-nistp256","scheme":"ecdsa-sha2-nistp256","key":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1Olb3zMAFFxXKHiIkQO5cJ3Yhl5i6UPp+IhuteBJbuHcA5UogKo0EWtlWwW6KSaKoTNEYL7JlCQiVnkhBktUgg=="}]}
    at verifySignature (/opt/n/lib/node_modules/corepack/dist/lib/corepack.cjs:21535:47)
    at fetchLatestStableVersion (/opt/n/lib/node_modules/corepack/dist/lib/corepack.cjs:21553:5)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async fetchLatestStableVersion2 (/opt/n/lib/node_modules/corepack/dist/lib/corepack.cjs:21672:14)
    at async Engine.getDefaultVersion (/opt/n/lib/node_modules/corepack/dist/lib/corepack.cjs:22292:23)
    at async Engine.executePackageManagerRequest (/opt/n/lib/node_modules/corepack/dist/lib/corepack.cjs:22390:47)
    at async Object.runMain (/opt/n/lib/node_modules/corepack/dist/lib/corepack.cjs:23096:5)

The thing triggered this error is the recent update of the npmjs.org integrity key.
corepack hard-coded the integrity key of npmjs.org, and it was updated recently, but corepack in many PCs and CIs are not updated yet since they are generally bundled in nodejs.

However, this error came from fetching the latest version of package manager, which is not necessary for projects who specify packageManager field.
Therefore, I think errors came from fetching the latest version of package manager should not be hard error.

I think not making a hard error will prevent future breakage.

Related: #613 #612 #616

Global impact.
As a workaround env var COREPACK_INTEGRITY_KEYS=0 helps

This issue is not mainly about unable to use newer version of pnpm (and other package managers), about inaccessibility with fresh corepack installation for projects has packageManager field.

And this issue is to prevent future similar problems, not current problem.
Current problem was fixed in #614 and other issues are there.

For reference, here is workarounds for current problem depending on your use case.

If you can, upgrading corepack to latest can solve this problem.

If this is not suitable for you, you can do:

For new version inaccessibility (like pnpm@10), we can use COREPACK_INTEGRITY_KEYS={key here} as auvred shows in Newly published versions of package managers distributed from npm cannot be installed due to key id mismatch #612 (comment).
For older version inaccessibility (like pnpm@8, 9.6.0), we can use COREPACK_DEFAULT_TO_LATEST=0 to skip unnecessary fetching of latest version.

@anatawa12

@anatawa12

Do you have some steps to reproduce for this issue?

The error I have shown above in description section is same as #612 #613.
To reproduce, use corepack 0.30 or earlier and tries to call pnpm without having local version cache at ~/.cache/node/corepack/lastKnownGood.json.

This issue is mainly about future similar issues so no real-world reproduction steps are there with latest corepack 0.31.

We can simulate the problem by COREPACK_INTEGRITY_KEYS={} (remove all recognized keys) without local cache with corepack 0.31.

@anatawa12

@anatawa12

The error I have shown above in description section is same as #612 #613. To reproduce, use corepack 0.30 or earlier and tries to call pnpm without having local version cache at ~/.cache/node/corepack/lastKnownGood.json.

This issue is mainly about future similar issues so no real-world reproduction steps are there with latest corepack 0.31.

We can simulate the problem by COREPACK_INTEGRITY_KEYS={} (remove all recognized keys) without local cache with corepack 0.31.

Thank you! Now I understand. This is quite likely to happen in CI where the cache isn't preserved between runs.

These steps will reproduce the issue:

npm install corepack@0.30.0 -g
cd $(mktemp -d)
corepack use pnpm@9.15.0
rm -rf ~/.cache/node/corepack
corepack enable
pnpm install

fetchLatestStableVersion causes the issue.

~~It does not happen with Yarn yet because there is not yet a release which is signed with a new key.~~

I have reproduced this issue in:

https://github.com/MikeMcC399/github-action/blob/test/corepack-pnpm-9.15.4/.github/workflows/example-basic-pnpm.yml for pnpm@9.15.4 (which was signed with the old key jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA)

$ npm view pnpm@9.15.4 dist.signatures.keyid
SHA256:jl3bwswu80PjjokCgh0o2w5c2U4LhQAE57gj9cz1kzA

Workaround

Set environment variable:

COREPACK_DEFAULT_TO_LATEST=0

or in GitHub Actions

env:
  COREPACK_DEFAULT_TO_LATEST: 0

chore(ci): fix corepack (#473)

fix: work around a corepack signature-verification bug on Render

Navigation Menu

Repository navigation

Please don't make error of fetching latest version information if packageManager field is specified. #625

Summary

Description

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Please don't make error of fetching latest version information if packageManager field is specified. #625

Description

Summary

Description

Activity

vytas-maciulskis commented on Feb 3, 2025

anatawa12 commented on Feb 3, 2025

MikeMcC399 commented on Feb 4, 2025

anatawa12 commented on Feb 4, 2025

MikeMcC399 commented on Feb 4, 2025

MikeMcC399 commented on Feb 4, 2025

Workaround

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions