ARTICLE · 软件编程
npm 暂存发布功能正式上线，在包发布前增加人工审批步骤
一语总结npm 发布了暂存发布功能，在构建包 tarball 与使其可安装之间插入一个需要 2FA 的人工审批步骤，旨在缓解供应链攻击，同时保持 CI 流水线不变。
现由 GitHub 维护的 npm 宣布暂存发布功能正式可用。与直接 npm publish 立即暴露某个版本不同，tarball 会先被放入一个暂存队列，该队列可通过 npmjs.com 和 CLI 查看。随后，维护者必须通过双因素认证挑战，才能将该版本提升到注册表；暂存步骤本身不需要 2FA，因此非交互式 CI 工作流不受影响。该功能要求 npm CLI 11.15.0+ 和 Node 22.14.0+，且包必须已存在于注册表中。关键子命令包括 npm stage publish、npm stage list、npm stage view、npm stage approve 和 npm stage reject。GitHub 建议将暂存发布与基于 OIDC 的可信发布结合使用，并将配置限制为仅暂存，从而阻止从 CI 直接发布。该公告还引入了新的 --allow-file、--allow-remote 和 --allow-directory 标志，与现有的 --allow-git 对应，后者在 v12 中将默认为 none。Hacker News 和 Reddit 上的社区反应不一，有人称赞这是重大的安全改进，也有人怀疑它不过是权宜之计；与此同时，pnpm、Yarn 和 release-it 等同类工具已经加入了类似的暂存功能。
- 暂存发布在包版本变为可安装之前增加了一个强制的人工审批步骤，并需要 2FA。
构建 tarball 后，维护者运行 `npm stage publish` 将其放入队列；只有通过 `npm stage approve` 完成 2FA 挑战后，版本才会提升到注册表，从而降低被攻破的 CI 发布风险。
- 该功能可与现有 CI 流水线配合使用，暂存步骤本身不需要 2FA。
暂存只会上传 tarball；非交互式 CI 可以继续使用相同的令牌，而存在性证明的要求转移到审批步骤，从而保留自动化灵活性。
- GitHub 建议将暂存发布与基于 OIDC 的可信发布结合使用，并将配置限制为仅暂存，以阻止从 CI 直接发布。
这种组合确保即使 CI 令牌被攻破，攻击者也无法绕过人工审批门禁，从而有效封堵一类 CI 接管发布攻击。
- 同类工具已迅速采用类似的暂存机制，表明业界广泛认可此类控制措施的必要性。
pnpm 11.3 添加了 `pnpm stage`，Yarn 提供 `yarn npm stage list`，release-it 支持 `"stage": true` 选项；同时 pnpm 默认也会延迟安装非常新的版本，作为补充防御。
npm 暂存发布功能正式上线，在包发布前增加人工审批步骤
现由 GitHub 维护的 npm 宣布暂存发布功能正式可用。与直接 npm publish 立即暴露某个版本不同，tarball 会先被放入一个暂存队列，该队列可通过 npmjs.com 和 CLI 查看。随后，维护者必须通过双因素认证挑战，才能将该版本提升到注册表；暂存步骤本身不需要 2FA，因此非交互式 CI 工作流不受影响。该功能要求 npm CLI 11.15.0+ 和 Node 22.14.0+，且包必须已存在于注册表中。关键子命令包括 npm stage publish、npm stage list、npm stage view、npm stage approve 和 npm stage reject。GitHub 建议将暂存发布与基于 OIDC 的可信发布结合使用，并将配置限制为仅暂存，从而阻止从 CI 直接发布。该公告还引入了新的 --allow-file、--allow-remote 和 --allow-directory 标志，与现有的 --allow-git 对应，后者在 v12 中将默认为 none。Hacker News 和 Reddit 上的社区反应不一，有人称赞这是重大的安全改进，也有人怀疑它不过是权宜之计；与此同时，pnpm、Yarn 和 release-it 等同类工具已经加入了类似的暂存功能。
文章金句
"每个向 NPM 发布的人都应该今天就把这个功能打开。
"往好处看，暂存发布是一个创可贴；更现实地看，我认为它从长远来看甚至会损害我们构建更安全基础设施的努力。
"它怎么可能有害？对于可信发布来说，这不是创可贴，而是一项重大改进，它消灭了整整一类 CI 被接管后的发布攻击。