Support signature verification against a custom COREPACK_NPM_REGISTRY

Start in sources/npmRegistryUtils.ts at verifySignature, then trace how COREPACK_NPM_REGISTRY, authentication, and COREPACK_INTEGRITY_KEYS affect trusted-key resolution. Done means custom registries can contribute keys from /-/npm/v1/keys without replacing bundled keys, explicit integrity keys still win, and failed or malformed key responses fall back safely.

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 (#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:

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.