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 和所有委托的 targets 角色。委托的 targets 角色 bins 进一步委托给 bin-n 角色，后者签署属于已注册 PyPI 项目的所有分发文件。

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

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

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

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

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

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

像 pip 这样的软件包管理器 必须 在用户最初下载的安装文件中附带 root 元数据文件。这包括有关所有顶层角色（包括根密钥本身）信任的密钥信息。软件包管理器还必须捆绑一个 TUF 客户端库。TUF 客户端库可能下载的任何新版本的 root 元数据都将根据最初与软件包管理器捆绑的根密钥进行验证。如果根密钥被泄露，但仍有足够的密钥安全，则 PyPI 管理员 必须 推送新的 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 元数据。如果最终没有通过 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 角色本身为大约 22 万个 PyPI 目标（即简单索引和分发）签名，则 bins 元数据的大小约为 42MB。本 PEP 不深入细节，但 TUF 具有一种所谓的 “哈希 bin 委托” 方案，将一个大型目标元数据文件拆分成许多小文件。这允许 TUF 客户端更新器智能地仅下载少量 TUF 元数据文件，以更新 bins 角色签名的任何项目。例如，将此方案应用于之前的存储库后，pip 下载 1.3KB 到 111KB 即可通过 TUF 安装或升级 PyPI 项目。

根据本文档更新以供实施时（2019 年 11 月 7 日）的调查结果（总结在表 2-3 中），PyPI 应 将 bins 角色中的所有目标拆分，并将它们委托给 16,384 个 bin-n 角色（参见表 2 中的 C10）。每个 bin-n 角色将签署其 SHA2-512 哈希落入该 bin 的 PyPI 目标（参见图 1 和 一致性快照）。结果发现，此数量的 bin 将导致回头用户产生 5-9% 的元数据开销（相对于下载的分发文件的平均大小；参见表 3 中的 V13 和 V15），而首次安装 pip 的新用户将产生 69% 的开销（参见表 3 中的 V17）。

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

1. 我们忽略了 root、timestamp 和顶层 targets 元数据。
2. pip 总是捆绑所有角色的最新良好元数据副本。

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

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

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

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

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

请注意，服务器上 bin 数量的更改对客户端是透明的。软件包管理器将需要下载一套全新的元数据，就像一个新用户一样，但此操作不需要任何显式代码逻辑或用户交互。

TUF 元数据可以通过二进制格式而非 JSON 文本格式表示，使其更紧凑。然而，数量足够多的项目和分发迟早会引入可伸缩性挑战，因此 bins 角色仍需要委托（如图 1 所示）来解决此问题。JSON 格式是一种开放且众所周知的数据交换标准，TUF 参考实现已支持该格式，因此本 PEP 推荐使用该数据格式。但是，由于委托数量庞大，所有元数据的压缩版本 也应 通过现有的 Warehouse HTTP 压缩机制提供给客户端。此外，JSON 元数据可以在发送给客户端之前进行压缩。TUF 参考实现目前不支持下载压缩的 JSON 元数据，但可以添加此功能以减小元数据大小。

推荐的密钥数量和类型

root 角色密钥对安全性至关重要，且应极少使用。它主要用于密钥撤销，并且是 PyPI 所有信任的中心。 root 角色签署授权用于每个顶层角色（包括其自身）的密钥。属于 root 角色 的密钥旨在得到严密保护，且使用频率最低。建议 PSF 董事会确定当前受信任的根密钥持有者集合，每位持有者将拥有一个（强）根密钥。其中大多数人可以构成法定人数，以撤销或赋予所有顶层密钥信任。或者，PyPI 的系统管理员可以被赋予签署 root 角色 的责任。因此， root 角色 应 要求 (t, n) 个密钥，其中 n 是由 PSF 董事会确定的密钥持有者数量，t > 1（以便至少两名成员必须签署 root 角色）。

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

出于类似原因， bins 角色的密钥设置 应 类似于 targets 角色的密钥。

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

管理在线密钥

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

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

无论此在线密钥存储在何处以及如何存储，其使用 应 仔细记录、监控和审计，理想情况下，以攻击者在攻破 PyPI 后无法立即关闭此记录、监控和审计的方式进行。

管理离线密钥

如前一节所述， root、 targets 和 bins 角色密钥 必须 离线以实现最大安全性。这些密钥将离线，意味着它们的私钥 绝不能 存储在 PyPI 上，尽管其中一些 可以 在项目的私有基础设施中在线。

应 有一个离线密钥仪式，以生成、备份和存储这些密钥，方式是只有 Python 管理员在必要时（例如，轮换顶层 TUF 角色的密钥）才能读取私钥。因此，密钥 应 最好在没有侧信道 攻击 问题的物理位置生成，使用

1. 一台可信的、 气隙隔离的 计算机，带有真随机数 生成器，并且在仪式后没有 数据 持久化
2. 受信任的操作系统
3. 一组受信任的第三方软件包（例如加密库的更新版本或 TUF 参考实现，如果受信任操作系统提供的版本不够新）

为了避免敏感数据（例如私钥）在仪式结束后持久化（除了备份介质上），离线密钥 应 使用强密码加密生成，优先级递减为：私有 HSM（例如 YubiHSM）、基于云的 HSM（例如上面列出的那些）、易失性内存（例如 RAM）或非易失性内存（例如 SSD 或 microSD）。如果密钥必须在非易失性内存上生成，则在安全备份密钥后，此内存 必须 不可恢复地销毁。

用于加密密钥的密码 应 存储在只有 Python 管理员才能访问的持久且值得信任的地方。

为了最大限度地减少仪式期间的 操作安全 错误， 应 编写脚本，在可信的密钥生成计算机上执行，以自动化仪式中繁琐的步骤，例如

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

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

一致性快照

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

为了保持一致性快照，所有 TUF 元数据在写入磁盘时 必须 在其文件名中包含版本号

VERSION_NUMBER.ROLENAME.json,

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

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

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

targets 或委托的 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。

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

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

更新一致性快照的 bin-n 元数据时，快照过程 应 还在相关的 bin-n 元数据中包含任何新的或更新的简单索引页面的哈希。请注意，简单索引页面可以在 API 调用时动态生成，因此保持其输出在一致性快照的有效期内稳定非常重要。

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

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

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

清理旧元数据

为了避免因不断生成新的持续快照而导致磁盘空间耗尽，PyPI 应 定期删除旧的持续快照，即在过去某个合理时间（例如 1 小时）已过时的元数据和目标文件。

为了保留最新的、一致的快照，PyPI 可以使用“标记-清除”算法。也就是说，从最新的、一致的快照的根目录开始，即从 timestamp 经过 snapshot 再到 targets 和委托的 targets，直到目标文件，标记所有访问过的文件，并删除所有未标记的文件。最新的几个一致快照也可以以类似的方式保留。

删除一致快照将导致客户端对该一致快照中任何文件的请求仅看到 HTTP 404 响应。客户端应（SHOULD）随后使用最新的、一致的快照重试其请求（如前所述）。

请注意，即使经过版本控制，root 元数据也不属于任何一致快照。PyPI 不得（MUST NOT）删除旧版本的 root 元数据。这保证了客户端可以更新到最新的 root 角色密钥，无论其本地 root 元数据多么过时。

发生密钥泄露时

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

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

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

遵循这些步骤将预防性地保护所有这些角色，即使其中只有一个可能被泄露。

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

还建议（RECOMMENDED）PyPI 充分记录安全公告中的泄露事件。当 pip-with-TUF 的用户因 timestamp、snapshot 或 root 角色的密钥不再有效而无法安装或更新项目时，这些安全公告将最具信息量。然后他们可以访问 PyPI 网站查阅安全公告，这将有助于解释为什么他们不再能够安装或更新，然后采取相应的行动。当由于泄露而未撤销一定数量的 root 密钥时，新的 root 元数据可以安全地更新，因为一定数量的现有 root 密钥将用于签署新 root 元数据的完整性。TUF 客户端将能够使用一定数量的先前已知的 root 密钥来验证新 root 元数据的完整性。这将是常见情况。否则，在最坏情况下，即由于泄露而撤销了一定数量的 root 密钥时，终端用户可以选择使用带外机制更新新的 root 元数据。

审计快照

如果恶意方泄露了 PyPI，他们可以使用任何在线密钥签署任意文件。具有离线密钥的角色（即 root、targets 和 bins）仍然受到保护。为了从仓库泄露中安全恢复，应审计快照以确保文件仅恢复到受信任的版本。

当检测到仓库泄露时，必须验证三类信息的完整性：

1. 如果仓库的在线密钥已被泄露，可以通过 targets 角色签署委托给新密钥的新元数据来撤销它们。
2. 如果仓库上的角色元数据已更改，这将影响由在线密钥签署的元数据。自上一个周期以来创建的任何角色信息都应丢弃。因此，新项目的开发者将需要重新注册他们的项目。
3. 如果目标文件本身可能已被篡改，可以使用存储在上次周期时存在的哈希信息来验证目标文件。

为了在发生泄露时安全地恢复快照，PyPI 应（SHOULD）维护少量自己的镜像，根据时间表复制 PyPI 快照。镜像协议可以立即用于此目的。镜像必须安全隔离，使其仅负责镜像 PyPI。镜像可以相互检查以检测意外或恶意的故障。

另一种方法是定期生成 snapshot 的加密哈希并发布到 Twitter。也许有用户会提供实际的元数据，仓库维护者可以验证元数据文件的加密哈希。或者，PyPI 可以定期存档自己的 snapshot 版本，而不是依赖外部提供的元数据。在这种情况下，PyPI 应（SHOULD）对仓库上的每个目标文件进行加密哈希，并将此数据存储在离线设备上。如果任何目标文件哈希发生变化，则表明发生了攻击。

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

哈希算法转换计划

如果用于哈希目标文件和元数据文件的算法变得脆弱，则应（SHOULD）将其替换为更强的哈希算法。

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

但是，一旦旧算法的支持被关闭，不支持新算法的客户端将只能通过禁用 TUF 验证来安装或更新软件包，包括客户端本身。为了让客户端在不暂时失去 TUF 安全保证的情况下进行转换，我们建议以下步骤。

1. 在 Warehouse 中实施新算法。
2. 重新生成现有、未过期的 TUF 元数据，以包含使用旧算法和新算法的哈希。所有新的元数据都应列出两种哈希算法。请注意，只有列出目标文件或其他元数据哈希摘要的 TUF 元数据需要更新，即 bin-n、snapshot 和 timestamp。因此，只需要在线密钥来签署更新的元数据。
3. 在高可见度渠道上宣布转换，例如Python Discourse 上的打包和 PyPI 变更邮件列表。
4. 让 pip 和 bandersnatch 等流行客户端有机会采用新的哈希算法。
5. 让最终用户有机会更新客户端。
6. 从 PyPI 维护者那里获得粗略共识以移除旧哈希算法。
7. 移除 Warehouse 对旧算法的支持，只支持新算法。