PyPI 上需要哪些其他存储库文件？

为了使像 pip 这样的包管理器能够使用 TUF 下载和验证分发文件，**必须**向 PyPI 添加一些额外的文件。这些额外的存储库文件称为 TUF 元数据，它们包含诸如哪些密钥可以信任、文件的加密哈希、签名、元数据版本号以及元数据应被视为过期后的日期等信息。

当包管理器想要检查更新时，它会要求 TUF 执行此操作。也就是说，包管理器永远不必处理这些额外的元数据或了解底层发生了什么。如果 TUF 报告回存在可用的更新，则包管理器可以要求 TUF 从 PyPI 下载这些文件。TUF 下载它们并根据它也从存储库下载的 TUF 元数据检查它们。如果下载的目标文件值得信赖，则 TUF 将它们传递给包管理器。

TUF 规范的文档格式部分提供了有关每种类型的必需元数据及其预期内容的信息。下一节介绍了**推荐**用于 PyPI 的不同类型的元数据。

此外，所有目标文件**应该**至少在磁盘上保存两次。一次使用其原始文件名，以提供向后兼容性，另一次在其文件名中包含其 SHA-512 哈希。这是生成一致快照所必需的。

根据使用的文件系统，**可以**使用不同的数据重复数据删除机制来避免目标文件硬盘副本导致存储空间增加。

签名元数据和存储库管理

顶级 root 角色为顶级 timestamp、snapshot、targets 和 root 角色的密钥签名。timestamp 角色为存储库元数据的每个新快照签名。snapshot 角色为 root、targets 和所有委托目标角色签名。委托目标角色 bins 进一步委托给 bin-n 角色，后者为属于已注册 PyPI 项目的所有分发文件签名。

图 1 提供了 PyPI 中可用角色的概述，其中包括顶级角色和 targets 委托的角色。该图还指示了用于为每个角色签名的密钥类型，以及哪些角色被信任为 PyPI 上可用的文件签名。接下来的两节将详细介绍签名存储库文件和每个角色使用的密钥类型。

图 1：PyPI 上可用的角色元数据概述。

变化最频繁的角色是 timestamp、snapshot 和 bins 委托的角色（即 bin-n）。每当 root、targets 或委托元数据更新时，**必须**更新 timestamp 和 snapshot 元数据。但是，请注意，root 和 targets 元数据不太可能像委托元数据那样频繁更新。类似地，只有在添加、更新或删除 bin-n 角色时，才会更新 bins 角色。因此，由于委托元数据为了支持项目的持续交付而频繁更新，timestamp、snapshot 和 bin-n 元数据很可能被频繁更新（可能每分钟更新一次）。持续交付是 PyPI 用于生成可以安全共存并独立于其他快照删除的快照的一组流程 [18]。

每年，PyPI 管理员**应该**为 root 和 targets 角色密钥签名。自动化将持续为所有项目的带时间戳的快照签名。有一个可用的存储库 元数据 API，可用于 管理 TUF 存储库。

在标准操作中，随着新分发文件上传到 PyPI，bin-n 元数据将被更新和签名。但是，还需要一个一次性的在线初始化机制，以便每次重新初始化 PyPI 时，为 PyPI 存储库中所有现有的分发文件创建和签名 bin-n 元数据。

如何建立对 PyPI 根密钥的初始信任？

像 pip 这样的包管理器**必须**将 root 元数据文件与用户最初下载的安装文件一起交付。这包括有关所有顶级角色（包括 root 密钥本身）的可信密钥的信息。包管理器还必须捆绑一个 TUF 客户端库。TUF 客户端库可能下载的 root 元数据的任何新版本都将根据最初与包管理器捆绑的 root 密钥进行验证。如果一个 root 密钥被泄露，但仍有足够数量的密钥是安全的，那么 PyPI 管理员**必须**推送新的 root 元数据，撤销对泄露密钥的信任。如果超过阈值的 root 密钥被泄露，则**必须**通过带外方式更新 root 元数据。（但是，应选择 root 密钥阈值，以使此事件极不可能发生。）如果在包管理器的新的版本之间撤销或添加了 root 密钥，则包管理器不需要立即更新，因为 TUF 更新过程会自动处理以前 root 密钥中的阈值数量为新的 root 密钥签名的情况（假设使用的 TUF 规范没有向后不兼容性）。因此，例如，如果一个包管理器最初附带了版本 1 的 root 元数据，并且版本 1 中的 root 密钥阈值数量为版本 2 的 root 元数据签名，并且版本 2 中的 root 密钥阈值数量为版本 3 的 root 元数据签名，那么该包管理器应该能够使用其 TUF 客户端库将其 root 元数据的副本从版本 1 透明地更新到版本 3。

因此，重申一遍，**必须**在与 CPython 一起发布的 pip 的任何新版本中（通过 ensurepip）包含 root 元数据的最新良好副本和 TUF 客户端库。包管理器中的 TUF 客户端库然后加载 root 元数据并下载其余的角色，包括在 root 元数据发生更改时更新它。有一个可用的 更新流程概述。

最小安全模型

在将 TUF 集成到 PyPI 时，需要考虑两种安全模型。本 PEP 中提出的模型是最小安全模型，它支持验证使用存储在 PyPI 上的私有加密密钥签名的 PyPI 分发文件。开发人员上传的分发文件由 PyPI 签名，并立即提供下载。本 PEP 的一个可能的未来扩展（在 PEP 480 中讨论）提出了最大安全模型，并允许开发人员为其项目签名。开发人员密钥不会在线存储：因此，项目可以免受 PyPI 泄露的影响。

最小安全模型不需要开发人员采取任何操作，并且可以防止恶意 CDN [19] 和公共镜像。为了支持上传分发文件的持续交付，PyPI 使用在线密钥为项目签名。此安全级别可以防止镜像或 CDN 意外或故意篡改项目，因为它们都没有为项目签名所需的任何密钥。但是，它无法保护项目免受已泄露 PyPI 的攻击者的攻击，因为他们可以使用在线存储的密钥操纵 TUF 元数据。

本 PEP 建议 bin-n 角色使用在线密钥为所有 PyPI 项目签名。这些 bin-n 角色**必须**全部由上层 bins 角色委托，后者使用离线密钥签名，并且依次**必须**由顶级 targets 角色委托，后者也使用离线密钥签名。这意味着当像 pip（即使用 TUF）这样的包管理器从 PyPI 上的项目下载分发文件时，它将查询 targets 角色以获取该分发文件的 TUF 元数据。如果最终 targets 通过 bins 委托的 bin-n 角色均未指定分发文件，则认为该分发文件在 PyPI 上不存在。

请注意，targets 不直接委托给 bin-n，而是使用中间 bins 角色的原因是，可以轻松地添加或删除其他委托，而不会影响 bins 到 bin-n 的映射。这对于 PEP 480 的实现至关重要。

元数据过期时间

root、targets 和 bins 角色的元数据**应该**分别过期一年，因为预计这些元数据文件很少更改。

timestamp、snapshot 和 bin-n 元数据**应该**分别过期一天，因为 CDN 或镜像**应该**每天与 PyPI 同步。此外，这个宽松的时间范围也考虑了高度偏差或漂移的客户端时钟。

元数据可扩展性

随着存储库中项目和分发文件数量的增长，TUF 元数据也需要相应地增长。例如，考虑 bins 角色。在 2013 年 8 月，发现如果 bins 角色本身为大约 220K 个 PyPI 目标（它们是简单的索引和分发文件）签名，则 bins 元数据的大小约为 42MB。本 PEP 不会深入探讨细节，但 TUF 具有一个所谓的 “哈希 bin 委托” 方案，该方案将大型目标元数据文件拆分为许多较小的文件。这允许 TUF 客户端更新程序智能地仅下载少量 TUF 元数据文件，以便更新 bins 角色签名的任何项目。例如，将此方案应用于以前的存储库后，pip 下载了 1.3KB 到 111KB 之间的数据以通过 TUF 安装或升级 PyPI 项目。

根据我们在更新此文档以进行实施时（2019 年 11 月 7 日）的发现，如表 2-3 中总结的那样，PyPI **应该**通过将其委托给 16,384 个 bin-n 角色来拆分 bins 角色中的所有目标（请参阅表 2 中的 C10）。每个 bin-n 角色将为其 SHA2-512 哈希值落入该 bin 的 PyPI 目标签名（请参阅图 1 和 一致快照）。发现这个数量的 bin 将导致返回用户的元数据开销为 5-9%（相对于下载的分发文件的平均大小；请参阅表 3 中的 V13 和 V15），而首次安装 pip 的新用户的元数据开销为 69%（请参阅表 3 中的 V17）。

计算这些元数据开销百分比时使用的一些假设

1. 我们忽略了 root、timestamp 和顶级目标元数据。
2. pip 将始终与所有角色的元数据的最新良好副本捆绑在一起。

C8 通过查询发布文件数量计算得出。C9 通过取过去 31 天下载的发布文件平均大小（1,628,321 字节）和磁盘上发布文件平均大小（2,740,465 字节）之间的平均值得出。Ee Durbin 在 2019 年 11 月 7 日提供了这些数字。

表 2：用于计算元数据开销的常量列表。

表 3：新用户和回访用户的元数据开销估计。

感兴趣的读者可以在这里找到元数据开销计算器的交互式版本 here

当回访用户的元数据开销超过 50% 时，存储桶的数量 SHOULD 增加。目前，当目标数量至少增加 10 倍，从超过 200 万个增加到超过 2200 万个时，SHOULD 发生这种情况，此时回访用户和新用户的元数据开销分别约为 50-54% 和 114%，假设存储桶数量保持不变。如果增加存储桶数量，则所有用户的成本将有效地成为新用户的成本，因为他们的成本将主要由下载 bins 元数据中大量委派（偶尔发生）的成本决定。如果新用户的成本被证明过高，主要是由于下载 bins 元数据的开销，则在发生这种情况之前，SHOULD 重新审视此问题。

请注意，服务器上存储桶数量的更改对客户端是透明的。包管理器将需要下载一组新的元数据，就像新用户一样，但此操作不需要任何显式的代码逻辑或用户交互即可执行。

可以通过以二进制格式表示 TUF 元数据而不是 JSON 文本格式来使 TUF 元数据更紧凑。然而，大量的项目和分发版将在某个时刻带来可扩展性挑战，因此 bins 角色仍然需要委派（如 图 1 中所述）才能解决该问题。JSON 格式是用于数据交换的开放且众所周知的标准，TUF 参考实现已支持该格式，因此本 PEP 建议使用该数据格式。但是，由于委派数量众多，SHOULD 也通过现有的 HTTP 压缩仓库机制向客户端提供所有元数据的压缩版本。此外，可以在将 JSON 元数据发送到客户端之前对其进行压缩。TUF 参考实现目前不支持下载压缩的 JSON 元数据，但可以添加此功能以减小元数据大小。

推荐的密钥数量和类型

root 角色密钥对安全性至关重要，应极少使用。它主要用于密钥撤销，并且是 PyPI 所有信任的中心。root 角色为每个顶级角色（包括其自身）授权的密钥签名。属于 root 角色的密钥旨在受到很好的保护，并且在所有密钥中使用频率最低。RECOMMEND PSF 董事会确定当前一组受信任的根密钥持有者，每个持有者都将拥有一个（强大的）根密钥。然后，他们中的大多数可以构成一个法定人数来撤销或赋予所有顶级密钥的信任。或者，可以赋予 PyPI 的系统管理员签署 root 角色的责任。因此，root 角色 SHOULD 需要 (t, n) 密钥，其中 n 是 PSF 董事会确定的密钥持有者数量，而 t > 1（因此至少需要两名成员签署 root 角色）。

targets 角色仅用于为所有目标到 bins 角色的静态委派签名。由于这些目标委派必须在发生泄露时抵御攻击，因此 targets 角色的密钥 MUST 脱机，并且独立于其他密钥。为了简化密钥管理，在不牺牲安全性的前提下，RECOMMEND 在创建 targets 角色的密钥并用于为该角色签名后永久丢弃它们。因此，targets 角色 SHOULD 需要 (2, 2) 密钥。同样，这是因为密钥将被永久丢弃，并且更多脱机密钥将无助于抵御密钥恢复攻击 [20]，除非保持加密算法的多样性。

出于类似原因，bins 角色的密钥 SHOULD 设置方式与 targets 角色的密钥类似。

为了支持持续交付，timestamp、snapshot 和所有 bin-n 角色的密钥 MUST 在线。要求所有这些角色使用不同的在线密钥几乎没有好处，因为如果攻击者泄露了 PyPI，他们大概能够泄露所有这些密钥。因此，为所有这些角色使用一个在线密钥是合理的。

管理在线密钥

timestamp、snapshot 和所有 bin-n 角色共享的在线密钥 MAY 存储在 Python 基础设施上，加密或不加密。例如，密钥 MAY 保存在自托管密钥管理服务（例如 Hashicorp Vault）或第三方密钥管理服务（例如 AWS KMS、Google Cloud KMS 或 Azure Key Vault）上。

其中一些密钥管理服务允许将密钥存储在硬件安全模块 (HSM) 上（例如，Hashicorp Vault、AWS CloudHSM、Google Cloud HSM 或 Azure Key Vault）。这可以防止攻击者泄露在线私钥（尽管无法阻止他们使用它，但他们的操作现在可能是加密可审计的）。但是，这需要修改 TUF 参考实现以支持 HSM (WIP)。

无论此在线密钥存储在哪里以及如何存储，SHOULD 仔细记录、监控和审核其使用情况，理想情况下，以一种攻击者泄露 PyPI 也无法立即关闭此记录、监控和审核的方式。

管理离线密钥

如上一节所述，root、targets 和 bins 角色密钥 MUST 脱机以获得最大安全性。这些密钥将脱机，因为它们的私钥 MUST NOT 存储在 PyPI 上，尽管其中一些密钥 MAY 在线存在于项目的私有基础设施中。

SHOULD 举行一次脱机密钥仪式来生成、备份和存储这些密钥，以便只有在必要时（例如，轮换顶级 TUF 角色的密钥时），Python 管理员才能读取私钥。因此，SHOULD 生成密钥，最好在不受旁道 攻击 影响的物理位置，使用

1. 一台受信任的、隔离 的计算机，配备真正的随机数 生成器，并且仪式结束后不会保留任何数据
2. 一个受信任的操作系统
3. 一组受信任的第三方软件包（例如，加密库的更新版本或 TUF 参考实现，如果受信任的操作系统提供的版本不够新）

为了避免在仪式结束后除了备份介质之外的其他地方保留敏感数据（例如，私钥），SHOULD 使用强密码加密生成的脱机密钥，方法是在（按信任度从高到低排序）：私有 HSM（例如，YubiHSM）、基于云的 HSM（例如，上面列出的那些）、易失性内存（例如，RAM）或非易失性内存（例如，SSD 或 microSD）中进行加密。如果必须在非易失性内存中生成密钥，则在安全地备份密钥后，MUST 不可恢复地销毁此内存。

用于加密密钥的密码 SHOULD 存储在某个持久且可信赖的位置，只有 Python 管理员可以访问该位置。

为了最大程度地减少仪式期间的 OPSEC 错误，SHOULD 为在受信任的密钥生成计算机上执行的脚本编写脚本，以自动化仪式的繁琐步骤，例如

• 通过 sneakernet 导出生成新密钥和替换旧密钥所需的所有代码和数据（以前的 TUF 元数据和 root 密钥）
• 加强防火墙，更新整个操作系统以修复安全漏洞，并将计算机与网络隔离
• 将所有新的 TUF 元数据和密钥导出到加密的备份介质。此备份提供了恢复 PyPI TUF 存储库所需数据的完整副本
• 将仅新的 TUF 元数据和在线密钥导出到加密的备份介质。此备份提供了导入到 PyPI 基础设施中的所有在线数据，例如，当需要从以前的存档状态恢复在线数据时，此备份非常有用
• 打印并保存新 TUF 元数据的加密哈希。此打印副本提供了额外的脱机纸质备份，可在发生泄露时用作比较

请注意，targets 和 bins 角色的一次性密钥 MAY 在脱机密钥仪式期间安全地生成、使用和删除。此外，root 密钥 MAY 不在脱机密钥仪式本身生成。相反，如上所述，n 个 Python 管理员中的阈值 t MAY 在用于生成所有其他密钥的脱机密钥仪式之后独立签署 root 元数据。

一致的快照

为了使 PyPI 上的 TUF 元数据与高度易变的目标文件保持一致，SHOULD 使用一致的快照。每个一致的快照捕获给定时间所有已知项目的状态，并且 MAY 安全地与任何其他快照共存，或独立删除，而不会影响任何其他快照。

为了维护一致的快照，所有 TUF 元数据 MUST 在写入磁盘时在其文件名中包含版本号

VERSION_NUMBER.ROLENAME.json,

其中 VERSION_NUMBER 是一个递增的整数，而 ROLENAME 是顶级元数据角色之一——root、snapshot 或 targets——或委托的目标角色之一——bins 或 bin-n。

唯一的例外是timestamp 元数据文件，当客户端执行更新时，其版本无法预先知道。timestamp 元数据列出了snapshot 元数据的版本，而snapshot 元数据又列出了targets 和委托的目标元数据的版本，所有这些都是给定一致快照的一部分。

在正常使用情况下，版本号溢出不太可能发生。例如，一个 8 字节的整数，可以每毫秒递增一次，并且可以持续近 3 亿年。如果攻击者任意增加版本号，存储库可以通过撤销受损密钥并重置版本号来恢复，如 TUF 规范中所述。

targets 或委托的目标元数据引用实际的目标文件，包括如上所述的其加密哈希。因此，要将目标文件标记为一致快照的一部分，它在写入磁盘时**必须**在其文件名中包含其哈希

HASH.FILENAME

其中 HASH 是文件内容哈希的十六进制摘要，FILENAME 是原始文件名。

这意味着每个目标文件**可能**有多个副本，每个副本对应上面指定的加密哈希函数之一。

假设磁盘空间无限、版本号严格递增且没有哈希冲突，客户端可以在 PyPI 生成另一个快照时安全地从一个快照中读取。

使用 TUF 协议的客户端（例如 pip）**必须**修改为下载每个元数据和目标文件，除了timestamp 元数据。这是通过在文件请求中包含文件名中的文件版本（对于元数据）或文件的加密哈希（对于目标文件）来完成的。

通过这种简单而有效的方式，PyPI 能够在给定时间捕获所有项目和关联元数据的一致快照。下一小节提供了此想法的实现细节。

注意：本 PEP 并不禁止使用高级文件系统或工具来生成一致的快照。在本 PEP 中提出简单解决方案有两个重要原因。首先，该解决方案不要求 PyPI 使用任何特定的文件系统或工具。其次，基于通用文件系统的方案允许镜像使用现有的文件传输工具（如 rsync）来有效地从 PyPI 传输一致的快照。

生成一致的快照

当新的分发文件上传到 PyPI 时，PyPI **必须**更新相应的bin-n 元数据。请记住，所有目标文件都按其文件名哈希排序到 bin 中。PyPI **必须**还更新snapshot 以考虑更新的bin-n 元数据，并更新timestamp 以考虑更新的snapshot 元数据。这些更新**应该**由自动化的快照过程处理。

文件上传**可能**并行处理，但是，一致的快照**必须**以严格顺序的方式生成。此外，只要分发文件是自包含的，就可以为每个上传的文件生成一致的快照。为此，上传进程将新的分发文件放入并发安全的 FIFO 队列中，快照进程一次读取一个文件并执行以下任务

首先，它将新文件路径添加到相关的bin-n 元数据中，递增其版本号，使用bin-n 角色密钥对其进行签名，并将其写入VERSION_NUMBER.bin-N.json。

然后，它获取最新的snapshot 元数据，更新其bin-n 元数据版本号，递增其自己的版本号，使用snapshot 角色密钥对其进行签名，并将其写入VERSION_NUMBER.snapshot.json。

最后，快照进程获取最新的timestamp 元数据，更新其snapshot 元数据哈希和版本号，递增其自己的版本号，设置新的过期时间，使用timestamp 角色密钥对其进行签名，并将其写入timestamp.json。

更新一致快照的bin-n 元数据时，快照进程**应该**还包括相关bin-n 元数据中任何新的或更新的简单索引页面的哈希。请注意，简单索引页面可能在 API 调用时动态生成，因此重要的是它们在一致快照的有效期内保持稳定。

由于快照进程**必须**以严格顺序的方式生成一致的快照，因此它构成了瓶颈。幸运的是，签名的操作足够快，可以每秒执行一千次或更多次。

此外，PyPI **可能**在生成相应的快照元数据之前向客户端提供分发文件。在这种情况下，客户端软件**应该**通知用户完整 TUF 保护尚未可用，但很快就会可用。

PyPI **应该**使用事务日志来记录上传过程和快照队列以进行审计，并在服务器故障后从错误中恢复。

清理旧元数据

为了避免由于不断生成新的快照而耗尽磁盘空间，PyPI **应该**定期删除旧的快照，即在过去一段时间内（例如 1 小时）被弃用的元数据和目标文件。

为了保留最新的快照，PyPI **可能**使用“标记和清除”算法。也就是说，从最新快照的根目录（即timestamp 通过snapshot 通过targets 和委托的目标）遍历到目标文件，标记所有已访问的文件，并删除所有未标记的文件。最后几个快照可以以类似的方式保留。

删除快照会导致客户端对该快照中任何文件的请求都只看到 HTTP 404 响应。然后，客户端**应该**重试其请求（如前所述）并使用最新的快照。

请注意，即使root 元数据已版本化，它也不是任何快照的一部分。PyPI **不得**删除旧版本的root 元数据。这保证了客户端可以更新到最新的root 角色密钥，无论其本地root 元数据有多旧。

密钥泄露事件

密钥泄露意味着一组阈值数量的密钥（属于 PyPI 上的元数据角色）以及 PyPI 基础设施已被泄露并用于在 PyPI 上签名新的元数据。

如果一组阈值数量的timestamp、snapshot、targets、bins 或bin-n 密钥已被泄露，则 PyPI **必须**采取以下步骤

1. 从root 角色中撤销timestamp、snapshot 和targets 角色密钥。这是通过用新发行的密钥替换被泄露的timestamp、snapshot 和targets 密钥来完成的。
2. 通过用新发行的密钥替换其密钥来从targets 角色中撤销bins 密钥。签名新的targets 角色元数据并丢弃新密钥（因为，如前所述，这提高了targets 元数据的安全性）。
3. 所有bin-n 角色的目标**应该**与最后一次已知的良好快照进行比较，在该快照中，没有一个timestamp、snapshot、bins 或bin-n 密钥被泄露。在泄露的快照中添加、更新或删除的目标，如果与最后一次已知的良好快照不匹配，**可能**会被恢复到其以前的版本。在确保所有bin-n 目标的完整性后，应在bins 元数据中更新其密钥。
4. bins 和bin-n 元数据**必须**递增其版本号、适当地延长过期时间并更新签名。
5. **必须**发出一个新的带时间戳的一致快照。

遵循这些步骤将先发制人地保护所有这些角色，即使其中只有一个角色可能已被泄露。

如果一组阈值数量的root 密钥已被泄露，则 PyPI **必须**采取上述步骤，并替换root 角色中的所有root 密钥。

也**建议**PyPI 使用安全公告充分记录安全漏洞。当使用带TUF的pip的用户无法安装或更新项目，因为时间戳、快照或根角色的密钥不再有效时，这些安全公告将提供最有用的信息。然后，他们可以访问PyPI网站查看安全公告，以帮助解释他们为什么无法再安装或更新，并据此采取行动。当由于安全漏洞导致未撤销的根密钥数量达到阈值时，可以使用阈值数量的现有根密钥来签署新根元数据的完整性，从而可以安全地更新新的根元数据。TUF客户端将能够使用阈值数量的先前已知的根密钥来验证新根元数据的完整性。这将是常见情况。否则，在最坏的情况下，如果由于安全漏洞导致阈值数量的根密钥被撤销，则最终用户可以选择使用带外机制更新新的根元数据。

审核快照

如果恶意方破坏了PyPI，他们可以使用任何在线密钥对任意文件进行签名。具有脱机密钥的角色（即根、目标和bin）仍然受到保护。为了安全地从存储库损坏中恢复，应审核快照以确保文件仅还原到受信任的版本。

当检测到存储库损坏时，必须验证三种类型的信息的完整性

1. 如果存储库的在线密钥遭到破坏，可以通过让目标角色签署将新密钥委托给新密钥的新元数据来撤销它们。
2. 如果存储库上的角色元数据已更改，这将影响由在线密钥签名的元数据。自上次期间创建的任何角色信息都应丢弃。结果，新项目的开发者需要重新注册他们的项目。
3. 如果目标文件本身可能被篡改，可以使用上次期间存在的目标文件的存储哈希信息对其进行验证。

为了在发生损坏的情况下安全地恢复快照，PyPI**应该**维护少量自己的镜像，以按照某个时间表复制PyPI快照。镜像协议可以立即用于此目的。镜像必须是安全的和隔离的，以便它们只负责镜像PyPI。可以相互检查镜像以检测意外或恶意的故障。

另一种方法是定期生成快照的加密哈希并发布到推特。也许用户会提供实际的元数据，并且存储库维护者可以验证元数据文件的加密哈希。或者，PyPI可以定期存档其自己的快照版本，而不是依赖于外部提供的元数据。在这种情况下，PyPI**应该**获取存储库上每个目标文件的加密哈希，并将此数据存储在脱机设备上。如果任何目标文件哈希已更改，则表明存在攻击。

至于提供不同版本元数据的攻击，或将发行版的版本冻结在特定版本上，可以使用TUF通过隐式密钥撤销和元数据不匹配检测[2]等技术来处理。

哈希算法过渡计划

如果用于对目标文件和元数据文件进行哈希计算的算法变得脆弱，则**应该**将其替换为更强大的哈希算法。

TUF元数据格式允许将来自不同哈希算法的摘要一起列出，以及算法标识符，以便客户端可以在算法之间无缝切换。

但是，一旦关闭对旧算法的支持，不支持新算法的客户端将只能通过禁用TUF验证来安装或更新软件包（包括客户端本身）。为了允许客户端过渡而不会暂时失去TUF安全保证，我们建议采用以下步骤。

1. 在Warehouse中实现新算法。
2. 重新生成现有的、未过期的TUF元数据，以包含使用旧算法和新算法计算的哈希值。所有新的元数据都将列出这两种哈希算法。请注意，只需要更新列出了目标文件或其他元数据哈希摘要的TUF元数据，即bin-n、快照和时间戳。因此，只需要在线密钥来签署更新的元数据。
3. 在高可见度渠道（例如Python Discourse上的打包和PyPI更改邮件列表）上宣布过渡。
4. 让pip和bandersnatch等流行的客户端有机会采用新的哈希算法。
5. 给最终用户机会更新客户端。
6. 获得PyPI维护者大致的共识以从PyPI中删除旧的哈希算法。
7. 删除Warehouse对旧算法的支持，只支持新算法。