Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Support signature verification against a custom COREPACK_NPM_REGISTRY

未关闭
  • 哪里不对？
#884 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
68/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
冷清
技术栈
nodejs, typescript
领域
cli, security, tooling

调研方向

从 sources/npmRegistryUtils.ts 中的 verifySignature 开始，然后跟踪 COREPACK_NPM_REGISTRY、身份验证和 COREPACK_INTEGRITY_KEYS 如何影响受信任密钥的解析。完成标准是：自定义 registry 可以从 /-/npm/v1/keys 提供密钥而不替换内置密钥，显式 integrity 密钥仍然具有优先级，并且失败或格式错误的密钥响应能够安全回退。

由索引模型根据 Issue 内容生成。

描述

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:

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.
主要语言
TypeScript
星标
3.8k
派生
281
平均合并
1 小时 47 分钟
30 天内合并 PR
2

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

nodejs/corepack 的其他 Issue

查看 nodejs/corepack 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。