你不应该信任Trusted Publishing

# 你不应该相信「可信发布」 原文：https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing ## ENOSUCHBLOG ## *编程、哲学、骑行。* - 主页 (https://blog.yossarian.net/) - 标签 (https://blog.yossarian.net/tags) - 系列 (https://blog.yossarian.net/series) - 收藏 (https://blog.yossarian.net/favorites) - 归档 (https://blog.yossarian.net/archive) - 主站 (https://yossarian.net/) - 今日所学 (https://yossarian.net/til) --- ## *2026年7月7日*标签：oss (https://blog.yossarian.net/tags#oss), python (https://blog.yossarian.net/tags#python), security (https://blog.yossarian.net/tags#security) --- ……因为「可信发布 (https://docs.pypi.org/trusted-publishers/)」不是为你（或我）而设的信任！它是为机器设计的。 「可信发布」是一种涉及*机器对机器*信任的认证方案。如果你发现自己以*你*（一个人类）不能（或能）信任它为由，去支持或反对「可信发布」，那么你犯了一个范畴错误——而 PyPI 正小心翼翼地帮你**避免**犯这个错误。 我在大约两年前 (https://blog.yossarian.net/2024/11/18/Security-means-securing-people-where-they-are) 间接提到了这一点，但只是暗示而非明确阐述。本文试图纠正这个错误。 ## 快速回顾 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#quick-recap) # 「可信发布」是 PyPI (https://pypi.org/) 用来描述一种基于 OpenID Connect (OIDC (https://openid.net/developers/how-connect-works/)) 联合认证形式的术语。PyPI 于 2023 年推出了它1 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:dev)，此后被其他打包生态系统广泛采用（包括 npm (https://docs.npmjs.com/trusted-publishers)、RubyGems (https://guides.rubygems.org/trusted-publishing/)、crates.io (https://crates.io/docs/trusted-publishing) 和 NuGet (https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-publishing)）。 「可信发布」背后的基本观察有两点： 1. 长期凭证（如索引 API 令牌）难以保护，而且往往范围过大，因为用户觉得确定「正确」的最小范围和过期时间很麻烦。因此，凭证泄露或被攻破时的影响范围可能远大于它原本被窃取的那个系统。 2. 许多用户专门为将其放入 CI/CD 平台而创建凭证，并随后从该平台进行发布。然而，CI/CD 平台通常*也*具有身份机制，允许用户通过 OIDC 展示对特定机器身份2 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:machine-identity) 的控制。 「可信发布」将这两点结合成一种认证方案：用户将其「可信发布者」（他们的 CI/CD 机器身份）与他们的包索引进行一次注册。然后，每当 CI/CD 出示身份令牌时，包索引验证该令牌，并颁发相应的、最小范围的、短期的发布凭证。 这不太容易想象；Seth Larson (https://sethmlarson.dev/) 的图表很有帮助： 「可信发布」的注册和颁发流程可视化。*（来源：OpenSSF (https://repos.openssf.org/trusted-publishers-for-all-package-repositories.html)）* 总的来说，这种短期、自限范围的凭证方法取得了**巨大成功**：我们发现用户3 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:pypi) 在无需手动管理凭证时更愿意使用，并且大型开源项目和企业都青睐将发布与源代码身份绑定，而不是与任何单个项目维护者绑定。 当然，「可信发布」并非完美：它有一个复杂的数据模型4 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:datamodel)，需要对索引选择的每个 OIDC 提供者进行特殊处理5 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:support)，并且（当然）仍可能被攻破（因为归根结底它仍然是一种认证方案，流程中某个地方*必须*存在凭证）6 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:compromised)。 尽管有这些限制，我认为「可信发布」对于采用它的打包生态系统来说是一个净收益。正如前文 (https://blog.yossarian.net/2024/11/18/Security-means-securing-people-where-they-are) 所提到的，安全关乎识别和保护用户集中信任的区域（他们的「饮水点」），而「可信发布」通过减少用户暴露于长期、范围过大的凭证数量来实现这一点。 ## 那信任呢？ (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#what-of-trust) # 到目前为止，我写的一切听起来都让「可信发布」相当不错，当然不是万能药。 那么，为什么强调**不要**信任它？ 这是一个重要的微妙之处：**「可信发布」只是一种认证方法**。「可信发布」**唯一**做的事情，是在外部机器身份（如 CI/CD 工作流）和索引上的包身份之间建立信任关系，**目的是为了认证上传行为**；它绝对**不能**告诉用户一个包是安全的、高质量的，或**任何其他信息**。 你可以很容易地向自己证明这一点：PyPI 是一个公开索引（这是设计使然），这意味着任何人都可以上传，*并且*任何人都可以使用「可信发布者」上传7 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:can)。因为任何人都可以使用，所以它们可以用于上传**任何东西**，包括恶意软件或漏洞代码。在这方面，它们与 API 令牌（PyPI 的另一种上传认证方法）**完全一样**。 PyPI **非常小心**8 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#fn:careful) 地**不**误导用户认为他们可以或应该根据包的「可信发布」状态来信任它。如果你去 PyPI 上某个项目的页面，你会注意到并没有「绿色魔法对勾」来标示项目的「可信发布」状态。 以 zizmor (https://pypi.org/project/zizmor/) 为例： zizmor 在 PyPI 上最新版本的截图 注意到这个页面上用户可控状态的唯一「绿色对勾」，是用于 PyPI 能够证明来自与包本身相同源的链接。这些链接也同样有意不被描述为「可信」；正如 PyPI 文档 (https://docs.pypi.org/project_metadata/#verified-details) 所解释的： > URL 被验证仅证明该 URL 在验证时由 PyPI 包所有者控制，并不暗示该 URL 或与该项目相关的任何其他关系的任何额外安全性。 如果你**确实**想查看 PyPI 上特定文件的「可信发布」状态，你需要去挖掘。你会发现在文件详情 (https://pypi.org/project/zizmor/#zizmor-1.26.1.tar.gz) 的深处，它被不加修饰地渲染为简单的「是/否」： 我用「不加修饰」是因为你可以**看到**在渲染「文件元数据」部分上投入的努力**多么少**，因为它**不是重要的信任信息**。我们甚至懒得正确渲染来自上传客户端用户代理的那段 JSON！ 这里同样可以看出，没有对「可信发布」状态施加任何规范性的信任声明：只有一个布尔状态，**完全没有任何东西**暗示用户因为该状态而可以或应该或多或少地信任一个项目。 ## 总结 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#summary) # 「可信发布」是一种在外部机器身份（如 CI/CD 工作流）与包索引/注册表上的一个或多个项目之间建立信任的机制。「可信发布」中的「信任」指的是这种信任关系，而不是其他任何东西。 它不是，也**不可能成为**，包信任或质量的信号。你**不能**用它来判断一个包是否安全或「好」，并且 PyPI **有意识地阻止**将其误用于此目的，通过不将其渲染为「绿色对勾」或任何类似的东西。 或者换一种说法：**「可信发布」只是一种认证形式**。它**除了告诉你上传已通过认证（所有上传到 PyPI 的包都经过认证）之外**，**不告诉你任何其他信息**。 谨向 Anatole France (https://www.goodreads.com/quotes/361132-the-law-in-its-majestic-equality-forbids-rich-and-poor) 表示歉意： > 「可信发布」，在其庄严的平等之下，允许经验丰富的维护者和脚本小子一样发布恶意软件、为了 HN 声望而输出垃圾、以及为尴尬的缺陷获得安全通告。」 ## 后记 (https://blog.yossarian.net/2026/07/07/You-shouldnt-trust-trusted-publishing#afterword) # 本文是关于「可信发布」的，**而不是**关于证明 (https://docs.pypi.org/attestations/)。证明是 PyPI 上一个技术上不同的主题，（目前）也使用 OIDC 机器身份，但**同样不是信任信号**。 打个比方：证明本质上是在机器身份之上的签名，但*任何人*都可以上传到 PyPI，因此*任何人*都可以用他们控制的任何机器身份进行签名。证明的*存在*并不由「可信发布者」的存在来保证，同样也不意味着任何特定的最终用户信任，**直到你**单独**建立对该身份的信任**。 这一点，也是明确记录在文档中的 (https://docs.pypi.org/attestations/security-model/#trustworthiness)。 --- ---