Skip to content

安全模型及注意事项

由于证明是用于断言有关某个软件包的某些事实的框架，因此证明的安全模型取决于断言的事实类型。

最基本的证明类型（默认启用的类型 pypa/gh-action-pypi-publish）断言该项目是由授权发布者（例如特定的 CI 提供商）在特定的代码存储库中发布的。

这种类型的证明有两个主要目的：

  • 它可以防止项目构建完成后被修改，例如在项目存储在软件包索引或镜像中时。
  • 它允许验证方观察项目受信任发布者的变更。例如，验证方可能会发现项目的新版本来自不同的受信任发布者，这表明项目的控制权可能已被恶意转移。

更高级的证明类型可以断言软件包的更多信息，例如在构建之前是否被篡改过，但这些证明需要专门的构建流程，因此比较少见。请参阅SLSA 常见问题解答中的“可复现构建怎么办？ ”。

一般性考虑

PyPI 对认证的支持建立在可信发布和Sigstore 的“无密钥签名”功能之上。下文将分别介绍各自的安全注意事项。

可信度

笔记

TL;DR：证明会告诉你PyPI 包的来源，但不会告诉你是否应该信任它。

与所有签名方案一样，人们很容易将证明文件的存在视为包裹可信度的证明。

然而，这并非证明（或任何类型的签名）所传达的含义。本质上，软件包上身份的有效签名表明在软件包构建过程中，该身份拥有访问权限。

换句话说：有效的签名并不能告诉验证方（例如，从 PyPI 安装软件包的用户）是否应该信任持有密钥的身份，或者是否应该信任恶意/易受攻击的代码是在构建之前或构建期间添加的。

举个具体的例子：PyPI 提供由GitHub 上的pypa/sampleproject 项目认证的sampleproject-4.0.0.tar.gz源代码 。这是一个 未经修改的来自该身份的证明，但它并 不能告诉用户是否应该信任pypa/sampleproject。要确定是否信任，用户必须自行决定是否信任 pypa/sampleproject。sampleproject-4.0.0.tar.gz

这种信任决策可能具有时间维度：用户可能 因为pypa/sampleproject是 sampleprojectPyPI 上该名称的第一个标识而决定信任它。然后，如果新版本sampleproject由新的标识（“”）认证pypa/evil-sampleproject，或者根本没有认证，用户可以自动观察到差异并开始进行修复。

可信出版

由于证明与受信任的发布者身份相关联，因此受信任的发布者 - 安全模型和注意事项中的所有注意事项 也适用于证明。

总的来说：虽然可信发布和证明比密码或长期有效的 API 令牌更安全、更不易被滥用，但它们并不能替代必要的安全措施，例如限制谁可以触发您的发布工作流。

使用 Sigstore 进行“无钥匙”签名

提示

Fulcio 的《证书颁发概述》更详细地记录了“无密钥”签名的颁发方面。

PyPI 对认证的支持是围绕“无密钥”（也称为“基于身份的”）签名构建的。

PyPI 项目不使用长期有效的签名密钥，而是通过与其受信任发布者之一匹配的身份进行签名。该身份通过类似于受信任发布所使用的 OpenID Connect (OIDC) 操作，以加密方式绑定到一个短期有效的签名密钥，但绑定对象是Sigstore：

  1. 受信任的发布/证明参与者（例如 GitHub Actions 工作流）由其身份提供商颁发 OIDC 令牌。

  2. 该 OIDC 令牌将与临时密钥对的公钥部分一起发送到 Sigstore 的公共证书颁发机构 (CA) Fulcio 。

    如果 OIDC 令牌有效（即未过期且由其声称的身份提供商颁发），Fulcio 将以 X.509 签名证书进行响应，该证书将 OIDC 令牌的声明与公钥绑定。

  3. 认证方现在可以用其临时密钥对的私钥部分进行签名。签名完成后，临时私钥即可丢弃，因为 X.509 签名证书会将公钥部分永久绑定到验证过程中使用的身份上。

这种“无密钥”方法体现了可用性和信任之间的权衡：与传统的长期签名密钥不同，它需要一个可信第三方 （Sigstore 的 Fulcio CA）来充当签名密钥与其关联身份之间的桥梁。作为对这个可信第三方的回报，Sigstore 提供与可验证身份绑定的、防滥用的短期签名密钥。

这与HTTPS中的权衡类似，其中 CA 作为可信第三方，将网站的身份（其域名）与其公钥绑定在一起。

与 HTTPS 生态系统类似，Sigstore 也采取措施减少对 Fulcio CA 的不必要信任：

  • Sigstore 运行着一个证书透明度(CT) 日志，可以对其进行监控和审计，以确认 Fulcio 不会为给定的身份颁发证书，除非获得该身份的真实凭证。

  • Sigstore 还运营着Rekor，作为“证书透明度”日志，有效地记录了使用 Fulcio 颁发的证书进行的每一次签名事件。与 CT 日志类似，Rekor 可以被监控和审计，以确认 Fulcio 颁发的证书没有被使用。

综合来看，这些透明机制通过使 Fulcio 的诚信可以通过加密方式进行审计和验证，从而削弱了人们对 Fulcio 的信任。

PyPI 的证明功能充分利用了这些信任缩减技术：除非证明中包含来自 Rekor 的包含证明以及来自 Fulcio 的 CT 日志的包含证明，否则证明不被视为已验证。