Skip to content

Support signature verification against a custom COREPACK_NPM_REGISTRY #884

Description

@opswithranjan

Summary

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.
  • .corepack.env is not loaded by the prepare / install subcommands (corepack use does not load COREPACK_NPM_REGISTRY from .corepack.env #741), so committing config doesn't help.
  • 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions