GitHub 改變了在發布頁面上自動生成“.tar.gz”和“.tgz”檔案的方式，這導致其校驗和發生變化，並導致自動構建系統（該系統將從GitHub 下載的檔案與之前的檔案進行檢查以確認完整性）發生大規模故障。 . 儲存的校驗和，例如，放置在包元資料或建置腳本中。
從版本 2.38 開始，Git 工具包預設包含 gzip 的內建實現，這使得跨作業系統統一對此壓縮方法的支援並提高存檔建立效能成為可能。 GitHub 在更新其基礎架構中的 git 版本後發現了這項變更。 這個問題是由於內建的基於zlib 的gzip 實作產生的壓縮檔案是二進位的，與gzip 實用程式建立的檔案不同，這導致在執行以下命令時，不同版本的git 建立的檔案的校驗和不同. “git 存檔”指令。
因此，在 GitHub 中更新 git 後，發布頁面上開始顯示略有不同的存檔，該存檔未通過使用舊校驗和的驗證。 這個問題體現在各種建置系統、持續整合系統和從原始碼建置包的工具中。 例如，大約 5800 個 FreeBSD 連接埠的彙編被破壞，其原始碼是從 GitHub 下載的。
為了回應有關這些故障的最初投訴，GitHub 最初提到了這樣一個事實：檔案的永久校驗和從未得到保證。 在發現需要進行大量工作來更新各個生態系統中的元資料以恢復受影響的建置系統的功能後，GitHub 代表改變了主意，恢復了更改並返回了生成檔案的舊方法。
Git 開發人員尚未做出決定，只是討論可能的行動。 考慮的選項包括恢復使用預設的 gzip 實用程式； 添加“--stable”標誌以保持與舊檔案的兼容性； 將內建實作連結到單獨的存檔格式； 對舊提交使用 gzip 實用程序，對從特定日期開始的提交使用內聯實作； 僅保證未壓縮檔案的格式穩定性。
做出決定的困難在於，回滾到對外部實用程式的呼叫並不能完全解決校驗和不變性的問題，因為外部 gzip 程式的變更也可能導致存檔格式的變更。 目前，已提出一組補丁供審查，預設會傳回舊行為（呼叫外部 gzip 實用程式），並在系統中沒有 gzip 實用程式的情況下使用內建實作。 這些補丁還在文件中添加了一個提示，即無法保證「git archive」輸出的穩定性，並且格式將來可能會發生變化。
來源： opennet.ru