opam 缓存处理中的安全性（2.1.5 之前）

我们很高兴 opam 2.1.5 已经发布，因为它包含一个安全修复，因为本地缓存被认为是可信的，并非所有校验和都会被验证。

从 2.0.0 版本开始，opam 使用下载缓存：如果需要源代码文件，首先会在本地缓存中查找其哈希值（~/.opam/download-cache/<hash-algorihm>/<hash>）。opam 支持多种哈希算法，缓存查找会遍历 opam 文件中存在的 所有哈希算法，以便构建、解包或安装。在 2.1.5 之前，未检查导致缓存命中的哈希算法（但检查了其他所有算法）。

如果一个包只指定一个（非弱）哈希算法，这会导致源代码文件被原样使用，在将文件写入缓存或从缓存中读取时出现的任何错误都无法检测到。此外，在某些情况下，如果下载缓存跨容器共享（可写）（例如在某些 CI 系统中），则会导致缓存中毒。

感谢 Raja 和 Kate，这个问题已在 PR 5538 中得到修复。

此问题的事件时间线如下所示

• 2023 年 2 月 23 日 对 opam 进行黑盒安全审计
• 2023 年 2 月 24 日 向 opam 团队报告
• 2023 年 2 月 27 日 与 opam 团队进行视频会议，进一步解释问题
• 2023 年 3 月 27 日 初步审查 opam 团队开发的补丁
• 2023 年 5 月 9 日 公开修复发现问题的 PR
• 2023 年 5 月 25 日 发布 opam 2.1.5

为什么我们关心 opam 的安全性？我们计划改进 opam 的供应链安全性，并开发 conex。在开发 conex 时，我们验证了 conex 对 opam 的假设。我们在 2023 年 2 月使用 opam 2.1.2 进行了验证，并将遗漏的假设报告给了 opam 开发团队。

我们的方法是黑盒测试，即我们使用 opam 二进制文件从自定义 opam 存储库安装包。我们没有深入研究 opam 的源代码，也没有彻底检查 opam：我们只测试了在开发 conex 过程中想到的假设。

与 opam 开发团队的合作非常棒，他们对我们的报告持开放态度并快速回复。我们不知道这个问题在现实中被利用过 - 在一些系统中，opam 沙箱 阻止了 opam 文件从内部写入下载缓存。