開發者工具 · SHA 雜湊計算器
內容尋址：Git、Docker 和 npm 如何使用 SHA 摘要作為名稱
· 背景
sha-256 碼頭工人 密碼學 開發人員工作流程
Git 提交、容器鏡像摘要和鎖定檔案完整性字串都是相同的想法：透過雜湊值命名資料。這篇文章解釋了內容尋址以及每個生態系統從中獲得的利益。
sha256：在你的 docker pull 中 - 該字串是什麼以及為什麼它對於同一映像永遠不會改變
版本控制系統、容器執行時間和套件管理器都使用相同的命名想法：檔案或位元組集合由其 SHA 摘要命名。在 Git 中，提交的 40 字元 SHA-1 標識符（或現代儲存庫中的 64 字元 SHA-256）是根據提交的內容（樹、作者、時間戳記和訊息）計算得出的。更改單一位元組，SHA 就會更改。在 Docker 中，每個層摘要都是該層內容的 SHA-256 哈希，並映像摘要是根據清單計算的。在 npm 和其他套件管理器中，完整性欄位儲存 tarball 的 SHA-512 摘要以驗證下載。內容尋址意味著名稱僅取決於字節，而不取決於中央資料庫或時間戳記。
好處是每個系統內的不變性。 git commit SHA-256:abc... 將始終引用相同的樹和訊息，因為雜湊決定了身分。如果有人聲稱使用相同的 SHA 進行了不同的提交，那麼他們就聲稱相同的位元組會產生兩個不同的雜湊值，這會破壞密碼學。重複資料刪除變得自動：兩個具有相同位元組的檔案產生相同的摘要，因此儲存系統可以儲存位元組一次並引用它們兩次。完整性檢查變得像重新計算摘要並進行比較一樣簡單：如果位元組在傳輸或靜止時被修改，則摘要不再匹配。
透過雜湊值命名資料 — 內容尋址思想以及為什麼它可以實現重複資料刪除和完整性自由
Git 儲存物件（提交、樹、blob 和標籤），並透過 SHA 摘要進行鍵入。 `git cat-file` 指令採用物件 ID 並擷取位元組。物件儲存是內容尋址的：您透過摘要請求，而不是透過位置或名稱。當您複製儲存庫時，git 會透過重新計算其摘要並檢查傳輸中打包的摘要來驗證每個物件。從 SHA-1 到 SHA-256 的過渡是漸進的；儲存庫可以支援兩者以實現相容性。磁碟格式儲存物件類型、大小和壓縮位元組。摘要是根據規範的未壓縮形式計算的。
現代 Git 儲存庫可以使用 SHA-256，並轉換正在進行中，因為 SHA-1 衝突現在是實用的（在 2017 中演示並在 2020 中改進）。使用 SHA-256 的儲存庫中的提交具有 64 字元十六進位標識符，而不是 40。 `git hash-object` 指令計算 blob（檔案內容）的 SHA，而不儲存它； `git commit-tree` 計算樹結構和訊息的 SHA。兩種操作都是確定性的：相同的位元組總是產生相同的摘要。這就是 GitHub 和其他偽造者如何一致地顯示提交 SHA 的方式——它們計算出與作者的克隆計算出的相同的摘要。
Git 使用內容尋址對象，該工具可以重現文字摘要；遷移詳細資訊需要特定於 Git 的來源
Docker 映像是分層建置的，其中每一層都是一個檔案系統增量（相對於上一層的變更）。 OCI 影像規範定義如何計算圖層的摘要和影像清單的摘要。層摘要是包含層檔案的壓縮 tar 檔案的 SHA-256。清單是一個 JSON 文件，列出了各層、它們的摘要和元資料。圖片摘要是清單 JSON 本身的 SHA-256 。當您使用 `latest` 之類的標籤拉取映像時，註冊表會尋找該標籤並傳回清單摘要。然後，您可以直接提取摘要，確保每次都獲得完全相同的位元組（所有層和元資料）。
本機映像上的 `docker inspect` 指令顯示其摘要。如果註冊表仍然保留指向相同清單的標記，則在兩台電腦上執行相同標記的相同映像會產生相同的摘要。內容尋址可讓映像供應鏈可稽核：CI/CD管道可以驗證其部署的映像是否與建置日誌中的摘要相匹配，並安全掃描器可以透過其摘要而不是透過可移動的標籤來報告已知具有特定漏洞的所有映像。
容器 — OCI 清單和層摘要，以及為什麼標籤可以移動但摘要不能移動
套件管理器使用摘要來驗證下載是否被竄改或損壞。在 npm 中， `package-lock.json` 檔案包含每個依賴項的 `integrity` 欄位，其中包含雜湊（通常為 SHA-512）和編碼（通常為 base64）。當 npm 下載 tarball 時，它會重新計算雜湊值並進行比較。如果哈希值不匹配，則安裝失敗。 Go 使用具有類似結構的 `go.sum` 檔案：模組路徑、版本和模組來源的 SHA-256 。 Cargo 在 `Cargo.lock` 中使用校驗和。原理是相同的：在首次解析依賴項時計算摘要，並在每次後續安裝時進行檢查。
完整性檢查不需要將包上傳到簽名機構或單獨儲存簽名。摘要是完整性檢查。為了獲得最大程度的保證，專案使用 Go 專案的透明系統簽署的 `go.sum` ，或 npm 完整性與其他驗證相結合，但基本情況很簡單：發布者計算一次摘要，將其記錄在鎖定檔案中，消費者端的工具驗證下載的位元組是否匹配。
包完整性編碼有所不同；此處僅斷言此計算器支援的 SHA 輸出
透過相同演演算法的相同位元組始終產生相同的摘要，無論位元組來自何處。開發人員的本機提交產生與 CI/CD 系統從相同儲存庫檢出相同修訂版相同的 SHA-256 。這種可重複性就是內容尋址運作的原因：您可以在不信任交付機制的情況下驗證工件。摘要成為一種加密承諾：即使更改一個位元組也會使其失效。
單獨分發摘要（在分發工件之前）可以防止進行中的修改。發布前發布的網頁可以顯示“expect SHA-256:abc...”，然後使用者可以根據它驗證下載。在公共儲存庫中發布的 git 提交是對位元組的承諾；摘要證明了這一點。
工作範例 — 從要摘要的位元組到工具使用的名稱的一個 blob
不同的系統對其摘要進行不同的編碼。 Git 預設使用小寫十六進位（40 或 64 十六進位字元）。 Docker 使用格式 `sha256:` 後面接著十六進位。 npm 和 Go 在完整性欄位中使用 base64。位元組相同；只是表示方式不同。 「abc」上的 SHA-256 摘要總是相同的 256 位，但您可能會將其視為 64 字元十六進位字串、44 字元 base64 字串或類似 `sha256:` 之類的標籤，後跟其中之一的標籤，後跟其中之一。編碼之間的轉換是無損的；每個表示中的摘要都是相同的值。
在比較不同工具的摘要時，了解編碼很重要。如果 Git 列印十六進位摘要並工具顯示 base64，則必須將一種表示形式轉換為另一種表示形式以驗證它們是否符合。 ToolAcre 的 SHA 雜湊計算器顯示每個摘要的十六進位和 base64，使其易於轉換或與其他系統交叉引用。
這不包括什麼 - 每個工具使用的特定編碼（十六進位與 Base64），在單獨的帖子中介紹
內容尋址並非特定於密碼學，儘管密碼雜湊使其安全。 CRC32 校驗和也是內容位址資料，但 CRC32 衝突很常見，並可以製造衝突；此儲存庫不會將 SHA-256 標記為損壞，而 CRC32 不作為對抗完整性原語提供。雜湊演演算法的選擇對於安全性至關重要：SHA-256 是需要針對對手進行完整性保護的系統的現代標準。 SHA-1 只是遺留的（Git 和其他人正在遷移）。選擇正確的演演算法與選擇內容尋址作為命名方案是不同的決定。
內容尋址與加密雜湊結合是現代軟體供應鏈完整性的基礎。您安裝的每個套件、執行的每個容器以及簽出的每個提交都可以被驗證為原始發布者預期的字節，而無需依賴安全傳輸（儘管安全傳輸仍然是良好的做法）。
重點：雜湊值就是身分 — ToolAcre SHA 雜湊計算器可讓您計算這些系統所依賴的相同摘要
內容尋址獨立於編碼、儲存位置或傳輸機制。無論是儲存在本機、CDN、登錄中或透過 HTTP 或安全 HTTPS 傳輸，相同的位元組都會產生相同的摘要。摘要是對位元組的加密承諾，驗證它只需要位元組和演演算法，不需要任何外部服務。這就是內容尋址支援離線驗證的原因：您可以透過不受信任的管道下載檔案，檢查摘要並了解位元組是否真實。
ToolAcre SHA 雜湊計算器可讓您計算這些系統所依賴的相同摘要。貼上字串或監視檔案，執行計算器並查看 Docker、Git、npm 和其他工具內部使用的 SHA-256、SHA-384 和 SHA-512 摘要。將計算出的摘要與原始來源中的摘要進行比較，以驗證位元組是否未被修改。計算器對您貼上的 UTF-8 文字進行雜湊處理；它不會散列檔案或金鑰材料，因此它可以散列的內容（文字輸入）和不能散列的內容（二進位檔案、編碼形式的加密金鑰）之間的界限是明確的並記錄在案。