opam 快取處理中的安全性問題（2.1.5 之前版本）

我們很高興 opam 2.1.5 已經發佈，因為它包含一個安全修復，由於本地快取被視為可信任的，因此並非所有校驗和都會被驗證。

自 2.0.0 以來，Opam 使用下載快取：如果需要原始碼成品，首先會在本地快取中查找其雜湊值（~/.opam/download-cache/<雜湊演算法>/<雜湊值>）。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 檔案內寫入下載快取。