pnpm 11.5 新增对 npm 分阶段发布的识别支持
pnpm 11.5 现已能够识别 npm 分阶段发布的审批信息，将其纳入发布元数据，从而避免这些发布被误认为是低可信度的包发布。
pnpm 11.5 现在将 npm 分阶段发布审批视为高度可信的信任证据，修复了一个可能导致使用 npm 新版 2FA 验证发布流程的包出现误报降级警告的问题。
这一变更正值 npm 在经历了一系列凭据窃取和令牌滥用事件后持续加强包发布控制之际。在 Mini Shai-Hulud 攻击活动中，攻击者利用被盗的 npm 令牌发布恶意包版本，促使 npm 撤销了细粒度访问令牌，并加速推进减少对长期有效发布凭据依赖的变更。分阶段发布将包版本置于预发布状态，在正式可安装之前，需要拥有发布权限的维护者通过 2FA 挑战来审批发布。
当包版本的注册表元数据包含 approver 字段时，pnpm 现在将其置于可信发布和来源证明之上。分阶段发布审批被视为 pnpm 最强的信任信号，而非被误认为是降级到安全性较低的传统令牌发布。
分阶段审批元数据触发了误报降级
此修复源于 Kevin Deng 提交的一份报告，他发现 pnpm 的 trustPolicy: no-downgrade 设置可能会错误地将分阶段发布审批视为从可信发布降级。
no-downgrade 策略旨在警告当一个包看起来从更强的发布机制降级到更弱的发布机制时的情况。这对于检测可疑变更非常有用，例如一个之前使用可信发布的包后来回退到经典账户或基于令牌的发布。
分阶段发布使该逻辑变得复杂。该问题指出，pnpm 似乎是通过检查 _npmUser 字段来推断包是否使用了可信发布。但当启用分阶段发布时，_npmUser 可能指向批准分阶段发布的 npm 用户。这使得包版本看起来像是虚假的降级，即使该发布仍然是通过可信发布流程进行的。
pnpm 11.5 通过将分阶段发布审批识别为独立的信任信号来解决此问题。如果注册表元数据包含 approver，pnpm 将该发布视为具有最强信任证据，而非将其归类为降级。
注册表元数据需要更清晰的发布信号
相关的 npm 社区讨论指出了一个更广泛的元数据问题，适用于包管理器和安全工具。
在该讨论中，Deng 要求 npm 公开明确的注册表元数据，显示包版本是如何发布的，包括是否使用了可信发布或分阶段发布。问题在于工具不应必须从 _npmUser 等字段推断发布安全属性，特别是随着 npm 添加更多发布模式。
npm 现在支持多种具有不同安全属性的发布路径：
- 经典发布 仍然可能涉及用户凭据、自动化令牌和 2FA，具体取决于项目的配置。
- 可信发布 允许维护者使用 OIDC 从支持的 CI/CD 提供商发布，而非使用长期有效的 npm 令牌。
- 分阶段发布 在版本正式可安装之前增加了审核步骤，需要拥有发布权限的维护者通过 2FA 挑战来审批发布。
这些机制也可以组合使用。npm 已声明分阶段发布可与可信发布配合使用，允许 CI 将版本推入预发布状态，而人工维护者则在发布前分别审批。对于包管理器和扫描器而言，这增加了根据注册表公开的元数据准确解读版本安全属性的新责任。
pnpm 的修复是包管理器如何适应 npm 新型安全模型的一个实践范例。随着注册表发布工作流程变得越来越精细，安装工具需要更精确的元数据来避免漏报警告和嘈杂的误报。
pnpm 11.5 中的其他供应链更新
pnpm 11.5 还包括多项其他与供应链相关的修复：
- 改进了
minimumReleaseAgeExclude处理，使被排除的包不会在 npm 解析快速路径中被固定到过时版本 - 在安装无关包后保留远程 HTTPS tarball 依赖项的
integrity字段 - 支持基于浏览器的 2FA 处理，用于对 npmjs.org 的
pnpm dist-tag add和pnpm dist-tag rm
对于分阶段发布，此次更新主要涉及避免错误分类。pnpm 11.5 防止分阶段发布被误读为从可信发布降级到经典用户或基于令牌的发布，这应该会减少使用 npm 新版发布控制的项目中嘈杂的 no-downgrade 警报。