You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When COREPACK_NPM_REGISTRY points at a private registry that re-signs packages with its own key, corepack prepare / corepack install fail with:
Usage Error: The package was not signed by any trusted keys
Corepack fetches package metadata and tarballs from the configured registry, but it only ever verifies signatures against the npm public keys bundled in config.json (or a manually supplied COREPACK_INTEGRITY_KEYS). It never consults the configured registry's own published keys, so a package signed by that registry can never be trusted.
Where it happens
sources/npmRegistryUtils.ts, verifySignature:
const{npm: trustedKeys}=process.env.COREPACK_INTEGRITY_KEYS
? JSON.parse(process.env.COREPACK_INTEGRITY_KEYS)
: defaultConfig.keys;// <-- always npmjs keys, even when COREPACK_NPM_REGISTRY is a private registry
The registry URL and auth are already known here (COREPACK_NPM_REGISTRY, COREPACK_NPM_TOKEN, etc.), but the registry's /-/npm/v1/keys endpoint is never fetched.
Why this can't reasonably be worked around by users
There's no way for many consumers (e.g. Dependabot jobs) to inject COREPACK_INTEGRITY_KEYS into the environment.
The result is broken installs for anyone behind a re-signing private registry (Cloudsmith, and similar), across every corepack-driven tool (npm/pnpm/yarn activation, and downstream tools like Dependabot and mise).
Proposed change
When a non-default COREPACK_NPM_REGISTRY is configured and COREPACK_INTEGRITY_KEYS is not explicitly set, corepack should fetch that registry's signing keys from <registry>/-/npm/v1/keys (the standard npm registry keys endpoint) and trust them in addition to the bundled npm keys.
Trusted-key resolution would become:
Config
Trusted keys
COREPACK_INTEGRITY_KEYS set
that value (unchanged, explicit override wins)
default npmjs registry
bundled npm keys (unchanged)
custom COREPACK_NPM_REGISTRY
registry's /-/npm/v1/keys+ bundled npm keys
Merging (rather than replacing) keeps working for registries that proxy packages while preserving npm's original signatures, and adds trust for packages the registry re-signs with its own key.
Rationale / trust model
Corepack already downloads and executes the package manager binary from COREPACK_NPM_REGISTRY. Trusting that same registry's published signing keys is strictly less privilege than that, and mirrors what the npm CLI already does (it verifies against the configured registry's keys). It also aligns with npm's registry signature spec, which defines /-/npm/v1/keys as the registry's key endpoint.
Safety
If the keys fetch fails or returns an empty/malformed body, fall back to the bundled npm keys rather than failing or disabling verification.
Prior art
dependabot/dependabot-core#15568 implements this externally by fetching the registry keys and injecting COREPACK_INTEGRITY_KEYS a workaround that would be unnecessary if corepack did this natively.
Summary
When
COREPACK_NPM_REGISTRYpoints at a private registry that re-signs packages with its own key,corepack prepare/corepack installfail with:Corepack fetches package metadata and tarballs from the configured registry, but it only ever verifies signatures against the npm public keys bundled in
config.json(or a manually suppliedCOREPACK_INTEGRITY_KEYS). It never consults the configured registry's own published keys, so a package signed by that registry can never be trusted.Where it happens
sources/npmRegistryUtils.ts,verifySignature:The registry URL and auth are already known here (
COREPACK_NPM_REGISTRY,COREPACK_NPM_TOKEN, etc.), but the registry's/-/npm/v1/keysendpoint is never fetched.Why this can't reasonably be worked around by users
COREPACK_INTEGRITY_KEYSinto the environment..corepack.envis not loaded by theprepare/installsubcommands (corepack use does not load COREPACK_NPM_REGISTRY from .corepack.env #741), so committing config doesn't help.Proposed change
When a non-default
COREPACK_NPM_REGISTRYis configured andCOREPACK_INTEGRITY_KEYSis not explicitly set, corepack should fetch that registry's signing keys from<registry>/-/npm/v1/keys(the standard npm registry keys endpoint) and trust them in addition to the bundled npm keys.Trusted-key resolution would become:
COREPACK_INTEGRITY_KEYSsetCOREPACK_NPM_REGISTRY/-/npm/v1/keys+ bundled npm keysMerging (rather than replacing) keeps working for registries that proxy packages while preserving npm's original signatures, and adds trust for packages the registry re-signs with its own key.
Rationale / trust model
Corepack already downloads and executes the package manager binary from
COREPACK_NPM_REGISTRY. Trusting that same registry's published signing keys is strictly less privilege than that, and mirrors what the npm CLI already does (it verifies against the configured registry's keys). It also aligns with npm's registry signature spec, which defines/-/npm/v1/keysas the registry's key endpoint.Safety
Prior art
dependabot/dependabot-core#15568implements this externally by fetching the registry keys and injectingCOREPACK_INTEGRITY_KEYSa workaround that would be unnecessary if corepack did this natively.