Gitプロジェクトは2026年末のGit 3.0リリースを目標に、新規作成されるリポジトリのデフォルトオブジェクト形式をSHA-256へ切り替える計画を進めている。このメジャーリリースでは同時に、Rustビルドツールチェーンの必須化、reftableバックエンドの標準化、長年非推奨とされてきたレガシーコマンドの削除も予定されている。正式リリースまではまだ猶予があるものの、周辺ツールチェーンの互換性検証は今すぐにでも着手すべき段階にある。
デフォルト値の変更が迫るエコシステム全体の再検証
コア開発チームは、既存のSHA-1形式のリポジトリはアップグレード後も問題なく動作し続けると強調している。この公式見解は、互換性破壊の影響をあくまで新規プロジェクトだけに限定できると印象づけようとするものだ。しかし実際の開発現場において、「新規リポジトリのみの影響」という説明は既存エコシステムの円滑な運用を断ち切るに等しい。開発者がローカル環境で検証用リポジトリを作成した瞬間、旧バージョンのIDEプラグインは読み込みに失敗する。長年メンテナンスされていないデプロイスクリプトも、二重フォーマットの解釈エラーという壁に直面することになる。
最大の懸念は、周辺ツールチェーンが「オブジェクトハッシュは40文字の16進数である」という前提に深く依存している点にある。新規リポジトリでは識別子が突如として64文字へと肥大化する。この文字列長の急激な変化は、過去十数年にわたり書かれてきた固定長抽出ルールや正規表現を一撃で無力化する。各種CI/CDシステムのログ解析モジュールは、新フォーマットのコミットノード情報を取得した最初のステップで切り捨て例外やパースエラーを吐き出すことになる。
図：コンテンツハッシュをキーとするGitのキーバリューストア構造。提供：GitButler / Butler’s Log
Git自体は2018年からSHA-256リポジトリの作成を実験的にサポートしており、セキュリティ要件の高いプロジェクトは手動で移行を選択できた。しかし8年もの移行期間を経ても、その重い負担を進んで引き受けるプロジェクトは皆無に等しかった。デフォルト値の強制変更こそが、エコシステム全体を動かす唯一の手段となってしまったのが実情である。
衝突攻撃と第二原像攻撃の決定的な違い
米国立標準技術研究所（NIST）は早くも2011年にSHA-1を非推奨リストへ追加しており、標準化団体の姿勢は十数年前から明確に示されていた。コア開発チームがデフォルト変更を推し進める表向きの理由も明快だ。業界全体で非推奨と宣告されたアルゴリズムの上に、新規リポジトリをこれ以上構築し続けるべきではないという危機感である。
これに対し、GitHubの共同創業者でありGitButlerの創設者でもあるScott Chaconらは、この議論が異なるレベルのセキュリティ脅威を混同していると反論する。セキュリティ研究界は2017年の「SHAttered」や2020年の「SHA-1 is a Shambles」において、SHA-1に対する実践的な衝突攻撃の手法を公開した。しかし、入念に細工された2つのファイルから同一のハッシュ値を導き出せることと、未知のオリジナルコードに対して意図した悪意あるコードを偽造する「第二原像攻撃」を成立させることとは、次元の異なる問題である。
実務レベルのソフトウェア工学において、既存リポジトリに対する第二原像攻撃は極めて天文学的な計算コストを要し、実現可能性はゼロに近い。仮にGitの検証アルゴリズムを、すでに完全に破綻したとされるMD5へダウングレードしたとしても事情は変わらない。世界中に存在する約30億台のハイエンドGPUをすべてRTX 5090へ置き換え、最大能力で計算を回し続けたとしても、第二原像の解読にはおよそ160億年を要する。現行のコンピューティング資源では、理論上の弱点と現実の攻撃との間にある計算力の断絶を埋めることは到底できない。
学術論文で示された衝突攻撃を実際の開発フローで再現するのも現実的ではない。攻撃者はまず対象リポジトリの書き込み権限を握り、膨大なバイナリエントロピーを巧妙に混入させたコードをコミットする必要がある。そのうえで、上流のメンテナーを欺いてその特定ブランチをマージさせなければならない。これほど手の込んだ環境を構築してまでマージを誘導する潜入手法は、実際のサイバー犯罪においてまったく採算が合わない。
信頼は暗号ハッシュではなく取得元に宿る
この議論は、バージョン管理システムのアーキテクチャが担うべき安全性の境界線に触れている。Linus Torvaldsは2005年のGit設計当初から、真の防壁は配布経路に存在するのであり、特定の計算式に依存するものではないと公言していた。開発者の作業環境の安全性を決定づける根幹は、「どの信頼できるサーバーからコードを取得したか」にある。それはローカルディスク上のファイルがどのハッシュ関数で計算されたかよりも遥かに重要である。
現実世界のサプライチェーン攻撃の大半は、暗号解読ではなくソーシャルエンジニアリングによって実行されている。攻撃者は長年放置されたオープンソースパッケージのメンテナーを買収するか、あるいは数ヶ月かけて熱心な貢献者を装い、コミット権限を奪取する手法を好む。2024年に発覚した「xz」のバックドア事件はその典型例である。正当なコード変更権限を手に入れてトロイの木馬を直接仕込むほうが、天文学的なコストをかけてハッシュ衝突を起こすよりも遥かに安上がりで確実だからだ。
アルゴリズムの強度を悪意ある注入を防ぐ主要な盾とみなす発想は、ビルドパイプラインにおける認証の死角を見落としている。有効なGPG署名が付与されたリリースタグの下で配布パッケージそのものをすり替える攻撃には、いかなるハッシュ衝突も不要だ。不正なコードの混入を防ぐ本質はリリースチャネルの厳格な検証体制にあり、ハッシュ長をどれほど引き伸ばしたところで、この運用上の隙間を埋めることはできない。
合わない採算：二重フォーマットの断絶と互換性の代償
デフォルト値変更における最大の難所は既存リポジトリの移行であり、それはバックグラウンドで透過的に完結するような性質のものではない。
図：リポジトリ作成時にハッシュ形式の明示的な選択を要求するホスティングプラットフォームのUI。提供：GitButler / Butler’s Log
プライベート環境や自社ホスティング環境でリポジトリを作成するチームは、クライアントとサーバーの両面で設定を手動調整しなければならない。ローカル環境の設定とサーバー側の対応状況に不整合が生じた瞬間、プッシュ操作は即座にブロックされ、基盤レイヤーから「fatal: the receiving end does not support this repository’s hash algorithm」という致命的エラーが返される。
大規模な既存リポジトリの移行は、長年蓄積された履歴データをすべて書き換えることを意味する。SHA-1リポジトリをSHA-256へ変換するには、すべてのblob、tree、commitオブジェクトを再計算しなければならない。この完全な再構築により、過去のコミットに付与されていたあらゆるGPG署名やSSH署名は無効化される。さらに、社内Wikiやチケット管理システム、チャットツールに残された無数の40文字コミットリンクは、一夜にしてすべてリンク切れのデッドリンクと化す。
Gitのサブモジュール構造はこの分断をさらに増幅させる。現在の仕様では、ネストされたサブモジュールは親リポジトリと同じオブジェクト形式を共有しなければならない。SHA-1のままの外部サブモジュールに依存するプロジェクトをSHA-256へ移行する場合、CIビルドサーバー上で両形式の依存関係を二重管理する必要が生じる。この並行同期の処理に少しでも齟齬が生じれば、チーム全体の自動化パイプラインは完全に停止する。
ネイティブなC実装のGitコマンドに依存せず、独自にGit仕様を再実装している周辺ライブラリ（libgit2など）の新アルゴリズム対応は著しく遅れている。Google社内では、全社の新規プロジェクトに対して旧フォーマット（SHA-1）の利用を義務付ける社内規則の策定が検討されているとも伝えられる。大手テック企業が基盤のアップデートをあえて凍結しようとするのは、シニアエンジニアのリソースを互換性トラブルの調査で浪費させないための現実的な防衛策にほかならない。
代替案：計算コストを署名レイヤーへ逃がすアプローチ
開発チームによるSHA-256の推進は決して思いつきによるものではない。移行期間におけるフォーマット間の相互運用マッピング設計は、メーリングリスト上で長年にわたり議論されてきた。システム設計者の視点から見れば、一時的な痛みを引き受けて今後数十年にわたる耐改ざん性を確保することは論理的な進化の道筋である。コア基盤の開発者は、アーキテクチャ上のあらゆる理論的弱点を根本から塞ぎたがる傾向がある。
一方、コミュニティの反対派は防御コストを実行可能な範囲に抑える現実解を模索している。独立系のメンテナーたちは、全ストレージ層のフォーマット変更を回避し、コミットやタグの署名オブジェクト内に別途計算したコンテンツ検証ヘッダーを付与する手法を提案している。これはColin Waltersが開発した「git-evtag」のアプローチに近い。
図：Gitオブジェクトの署名フィールドに独立したコンテンツハッシュを注入する構造。提供：GitButler / Butler’s Log
この設計は、改ざん防止に必要な計算負荷を署名検証のフェーズへ局所化させる。不正を試みる攻撃者は、互いに独立した2つの検証体系を同時に突破することを強いられる。
独立した検証ヘッダーを採用する最大の強みは、日常の開発作業への影響を完全に遮断できる点にある。実測値によれば、210万個のファイルと35GBの容量を抱えるChromiumリポジトリのツリー全体を再ハッシュするのに要した時間はわずか5秒だった。Linuxカーネルの1.5GBのツリーであれば257ミリ秒、一般的な小規模プロジェクトなら17ミリ秒で完了する。計算負荷をリリースタグを打つ瞬間だけに集約できれば、日常的に発生する無数のコミットに対して余計な計算コストを課さずに済む。
コードベースを新規格へ移行することで得られるのは、今後数十年の理論的な安全マージンである。一方でデフォルト値を据え置くことで守られるのは、エコシステム全体が支払わずに済む膨大な移行コストだ。双方の主張の前提は極めて明確である。ハッシュ値そのものが信頼の基盤であると信じるならば移行は急務であり、信頼は配布元から得られると考えるならば緊急性は低い。メーリングリストで長年議論されてきた相互運用マッピングこそが、この不可逆な変革を軟着陸させる唯一の防波堤となる。
参考リンク：
- Git 3.0 and the SHA-256 Migration
- The hidden cost of Git’s SHA-256 migration
