Git 3.0のSHA-256既定は『高くつく誤り』とChacon氏

Scott Chacon氏は、Git 3.0で新規リポジトリの既定ハッシュをSHA-256にするというGitの計画は、高くつく誤りになると述べています。2026年9月30日にGitButlerのブログで公開されたこの主張は、Gitプロジェクト自身が「周辺エコシステムの準備が整うまで切り替えは待つ」と述べているさなかに出てきました。この論争が重要なのは、GitのコミットIDを保存したり解析したりするあらゆるツールが、その答えに左右されるからです。

Tech AI Wireは9月にGit 3.0の計画を報じました。新規リポジトリはSHA-256のオブジェクト名、reftable形式、mainブランチを持つようになり、GitのビルドにはRustが必要になります。

Chacon氏の主張

Gitはすべてのファイル、フォルダ、コミットをハッシュで識別します。ハッシュとは、内容から計算される固定長の指紋のようなものです。Gitは当初からこの用途にSHA-1アルゴリズムを使ってきました。SHA-1は弱いことが知られています。十分な労力をかければ、研究者は同じ指紋を持つ2つの異なる入力を作れます。これを衝突と呼びます。

Chacon氏の主張は、この弱点はGitにとっては理論上のものだ、というものです。SHA-1の数学的な欠陥が知られているにもかかわらず、数十億のGitリポジトリの中で衝突が記録された例はない、と同氏は書いています。

次に同氏はコストを列挙します。SHA-256のリポジトリは、既存のSHA-1ハッシュをすべて壊します。URL、バグトラッカー内のコミット参照、その他40文字のIDを引用しているあらゆるものが一致しなくなります。ほとんどのGitライブラリ実装はSHA-256を完全にはサポートしていない、とも同氏は述べています。

同氏の代案は、オブジェクト名を変えずに整合性を検証することです。Chacon氏によると、チェックアウト済みのツリー全体のハッシュ計算は高速です。同氏のテストでは、210万ファイルからなる35GBのChromiumツリーで約5秒、1.5GBのLinuxカーネルで257ミリ秒でした。同氏は、署名付きオブジェクトにSHA-1の名前と並べてSHA-256のチェックサムを埋め込むことを提案しています。そうすればプロジェクトは、エコシステムを二分せずに、より強いハッシュで検証できます。この発想の先例として、同氏は2015年のツールgit-evtagを挙げています。

Gitプロジェクトの説明

Git自身の破壊的変更の文書は、Chacon氏が反対している計画を説明しています。Git 3.0は、新しく初期化されるリポジトリに限って既定ハッシュをSHA-256に変えます。既存のSHA-1リポジトリは動き続け、SHA-1オブジェクト形式を非推奨にする計画はないと文書は述べています。

文書は、プロジェクトがこの変更を望む理由も説明しています。SHA-1は暗号学的に破られているとし、その根拠を列挙しています。

出来事	年
NISTがSHA-1を非推奨に	2011年
SHAppening攻撃	2015年
SHAttered衝突	2017年
GitがSHA-256を後継に選定	2018年末
誕生日ニア衝突攻撃	2019年
Shambles攻撃	2020年

文書の2つの点はChacon氏に有利に働きます。Gitプロジェクトは、ライブラリ、ホスティングプラットフォーム、サードパーティのアプリケーションがSHA-256への準備を示すまで、この変更は行わないと述べています。そしてGit 3.0の公開日を定めていません。以前の報道は2026年末ごろの公開を見込んでいましたが、文書自体は日付を挙げていません。

移行はどう進む想定か

Gitのハッシュ関数移行の設計文書を見ると、プロジェクトが相互運用性を考え抜いてきたことが分かります。SHA-256の選定は2018年末にさかのぼります。この設計では、各リポジトリが自分のペースで移行できます。SHA-256リポジトリは双方向の変換テーブルを持ち、移行期間中はどちらのハッシュでもオブジェクトを参照できます。

ネットワーク操作もカバーされています。設計文書は、SHA-256サーバーとSHA-1サーバーの間でのプッシュとフェッチを、パック作成時にオブジェクトを変換することで実現すると説明しています。コミットは2つの署名を持てます。既存のgpgsigフィールドと、新しいgpgsig-sha256フィールドです。作業は5つのフェーズに分かれ、十分な数のリポジトリが移行した時点での完全移行で終わります。制約は2つ残ります。SHA-1リポジトリとSHA-256リポジトリの間では、シャロークローンとalternatesが機能しません。

目に見える違いは長さです。SHA-1のオブジェクト名は16進数40文字、SHA-256の名前は64文字です。

開発者にとっての意味

今日の時点で変わることはありません。Git 3.0に公開日はなく、既存のリポジトリはいずれにせよSHA-1のままです。問題は、新しい既定値がいつ来るにせよ、その前に何をしておくかです。

第一に、SHA-256リポジトリに対して自分のツール群を今テストしてください。ほとんどのGitライブラリが完全にはサポートしていないというChacon氏の主張は、検証できます。SHA-256モードでテスト用リポジトリを作り、CIスクリプト、デプロイフック、コードレビュー連携をそれに対して走らせてみてください。

第二に、40文字のIDを前提にしているものをすべて洗い出してください。その長さを決め打ちしたデータベースの列、正規表現、URLパターンは、64文字の名前を切り詰めるか拒否します。9月の記事でも同じ点を指摘しました。Chacon氏の投稿は、この破損が保存されたあらゆるリンクに広がることを思い出させてくれます。

第三に、同氏の代案をその中身で評価してください。懸念が名前付けではなく改ざん検知なら、ツリーに対する署名付きチェックサムは、形式変更なしに今日それを実現します。SHA-256のオブジェクト名が必要なら、移行設計はすでにSHA-1との相互運用を保ったリポジトリ単位の移行をサポートしています。3.0を待つ必要はありません。

最後に、バージョン番号ではなくプロジェクトの準備判定を見てください。破壊的変更の文書は、既定の切り替えをエコシステムの準備状況に結び付けています。つまり、いつ起きるかを決めるのはGitのリリース予定表ではなく、フォージとライブラリです。