Github で行われた変更は期待どおりではありませんでした
最近、GitHubがリリースページで自動生成される「.tar.gz」ファイルと「.tgz」ファイルの生成方法を変更したと報じられました。
この変更によりチェックサムに変化が生じ、 GitHubからダウンロードしたファイルの整合性を、パッケージメタデータやビルドスクリプトなどに保存されているチェックサムと照合して検証する自動ビルドシステムに大規模な障害が発生しました。
バージョン2.38以降、Gitにはgzipの組み込み実装がデフォルトで含まれるようになり、すべてのオペレーティングシステムでこの圧縮方式との互換性が統一され、ファイル作成のパフォーマンスが向上しました。GitHubは、自社のインフラストラクチャ上のGitバージョンを更新した後、この変更を採用しました。
Git ファイルのデフォルトの圧縮が最近変更されました。 その結果、コンテンツが完全に変更されていなくても、GitHub からダウンロードされたファイルのチェックサムが異なる場合があります。
GitHub は、自動生成されたファイルのチェックサムの安定性を保証しません。 これらは、[バージョン] タブで「ソース コード (zip)」および「ソース コード (tar.gz)」という言葉でマークされています。 一貫したチェックサムに依存する必要がある場合は、ファイルを GitHub リリースに直接アップロードできます。
これらは変更されないことが保証されています。
問題は、 zlibに組み込まれているgzip実装によって生成される圧縮ファイルが、gzipユーティリティによって生成されるファイルとは異なるバイナリであるため、 「git archive」コマンドを実行した際に、異なるバージョンのgitによって作成されたファイルのチェックサムが異なる結果となることでした。
その結果、GitHubでgitを更新した後、以前のチェックサムでは検証に失敗した、わずかに異なるファイルがリリースページに表示されるようになった。
この問題は、さまざまなビルド システム、継続的インテグレーション システム、およびソースからパッケージをビルドするためのツールキットで明らかになりました。 たとえば、FreeBSD の約 5800 ポートが壊れており、そのソースは GitHub からダウンロードされました。
当初、不具合に関する苦情が寄せられた際、 GitHubの担当者は、ファイルのチェックサムの一貫性は決して保証されていないと指摘した。
変更の影響を受けるビルド システムを作成するには、さまざまなエコシステム全体でメタデータを更新するためにかなりの作業が必要になることが示された後、GitHub は心変わりし、変更を元に戻し、古いファイル生成方法に戻しました。
予想通り、人々は不満を言い始めた。GitHubの従業員（そして主要なGit貢献者）であるブライアン・M・カールソンの最初の反応は、必ずしも同情的とは言えなかった。
私が言っているのは、ポリシーが正しかったことはなく、Git が保証したことがないように、ファイルの安定したチェックサムを保証したこともないということです。 ここで機能していないことをお詫び申し上げます。過去にこれについて明確なコミュニケーションがありませんでしたが、私たちのポリシーは 4 年以上変更されていません。
Git開発者はまだ決定を下しておらず、可能な対応策について議論している段階です。検討されている選択肢には、デフォルトのgzipユーティリティに戻すこと、古いファイルとの互換性を維持するために`--stable`フラグを追加すること、組み込みの実装を別のファイル形式に紐付けること、古いコミットにはgzipを使用し、特定の日付以降のコミットには組み込みの実装を使用すること、圧縮されていないファイルのみに形式の安定性を保証することなどが含まれます。
この決定の複雑さは、外部 gzip プログラムの変更によってファイルも変更される可能性があるため、外部ユーティリティ呼び出しに戻ってもチェックサムの不変性の問題が完全には解決されないという事実によって説明されます。
現在、システムに gzip ユーティリティが存在しない場合にデフォルトの動作 (外部 gzip ユーティリティを呼び出す) に戻し、組み込み実装を使用するレビュー用のパッチ セットがあります。 このパッチでは、「git アーカイブ」の出力が安定しているとは保証されておらず、形式が将来変更される可能性があるという注記もドキュメントに追加されています。
最後に、これについてさらに詳しく知りたい場合は、以下のリンクから詳細をご覧いただけます。