npm 可信发布新增可选 dist-tag 权限
2026-10-01
npm 的可信发布配置现在可以被授予管理 dist-tags 的权限（例如，将某个版本提升为 latest，更新 next 和 beta 指针），使用短期 OIDC 凭证，而不是长期访问令牌。
以前，可信发布涵盖发布和暂存，但不包括 dist-tag 操作。
这意味着，在其他方面已完全转向无令牌、基于 OIDC 工作流的维护者，仍然不得不保留一个细粒度访问令牌，仅仅为了在发布或回滚后管理标签。
每个可信发布配置现在都有一个需选择加入的“允许 npm dist-tag”权限。
对于新配置和现有配置，它默认关闭，因此没有任何配置会自动获得新能力。
该权限独立于直接发布，因此仅用于暂存的配置也可以被授予 dist-tag 管理权限。
如果传入的 OIDC 令牌与任何启用了该权限的配置匹配，则 dist-tag 操作会被授权。
现有的基于令牌的 dist-tag 管理继续照常工作，没有变化。
要使用它，请打开你的包的可信发布设置，并在应能管理标签的配置上启用“允许 npm dist-tag”。
了解有关 npm 可信发布者的更多信息。
加入我们的路线图讨论。
npm 可信发布配置现在可选授予 dist-tag 管理权限，允许用短期 OIDC 凭证执行 latest、next、beta 等标签操作，而不必为发布后或回滚后的标签管理保留长期令牌。该权限默认关闭，且独立于直接发布权限；现有 token 方式仍可用。
- npm 可信发布配置现在可选授予 dist-tag 管理权限，允许用短期 OIDC 凭证执行 latest、next、beta 等标签操作，而不必为发布后或回滚后的标签管理保留长期令牌。该权限默认关闭，且独立于直接发布权限；现有 token 方式仍可用。
- 原贴提到：Trusted publishing configurations for npm can now be granted permission
- 来源：github.blog
这是 npm 可信发布信任模型的一次权限扩展：过去 OIDC 可信发布覆盖发布与暂存，现在可以按配置选择加入 dist-tag 管理。dist-tag 虽然不改变版本包内容，却决定用户安装时会命中 latest、next、beta 等标签，因此它属于发布链路上的关键“指针控制”能力。
为什么重要
意义在于把无长期令牌的发布流程补完整。此前维护者即使已经用 OIDC 完成发布，仍可能为了发布后提升 latest 或回滚标签而保留细粒度 token；这等于在供应链上留下一个长期凭证。新权限允许用短期 OIDC 凭证完成这些操作，且默认关闭，不会自动扩大现有配置权限。
对谁有价值
对使用 npm trusted publishing 的包维护者、依赖自动化发布的工程团队、需要做发布后晋升或回滚的 release owner 最有价值。对安全团队也有价值，因为可以减少必须轮换和审计的长期 token。
可以怎么行动
- 审查包的 trusted publishing 配置，确认哪些配置需要管理 dist-tags。
- 只在必要配置上启用“允许 npm dist-tag”，遵循最小权限。
- 将发布后提升 latest、更新 next/beta、回滚等操作迁移到 OIDC 流程，随后清理仅用于标签管理的冗余 token。
- 记录哪些配置拥有该权限，并纳入发布权限审计。
风险或限制
- 该权限默认关闭，不手动开启就不会生效；不要误以为升级后自动具备能力。
- 授权逻辑是传入 OIDC token 匹配任一启用权限的配置即可，因此配置越多，授权面越需要审查。
- dist-tag 直接影响用户安装路径，误把版本提升为 latest 或改错 next/beta 会影响下游；权限应只授予可信工作流。
- 现有 token 方式仍可用，过渡期可能同时存在 token 与 OIDC 两条路径，需要避免权限重叠和遗漏。
来源信号为 GitHub Changelog。整体判断：这是 npm 供应链安全向更细粒度、默认保守、OIDC 优先推进的明确动作，适合被纳入团队的发布安全基线与权限治理清单。
这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。
如果把《npm 可信发布新增可选 dist-tag 权限》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。