Git 3.0は単なるバージョン番号以上の意味を持つ
Git 3.0は、2014年のGit 2.0リリース以来、このバージョン管理システムにとって初となる破壊的変更を伴うメジャーリリースとなる見込みです。公式なリリース日は未定ですが、開発者やインフラに影響を与える2つの重要な変更が計画されています。Rustが必須のビルド依存関係となり、SHA-256が新規リポジトリのデフォルトハッシュアルゴリズムとして予定されています。
Rustへの移行はメモリ安全性の向上を目的としており、GitのC言語コードベースにおける一般的なセキュリティ脆弱性の原因に対処するものです。近年のGit 2.xリリースではRustコンポーネントがデフォルトで有効化されてきましたが、Git 3.0ではコンパイル時にこれらを無効化するオプションが削除され、Rustがソフトウェアビルドの前提条件となります。
同時に、プロジェクトでは新規リポジトリのデフォルトハッシュをSHA-1からSHA-256へ移行する計画です。この変更により、コミットハッシュは40文字から64文字に拡張され、短い形式を前提としている既存のツール、スクリプト、継続的インテグレーション（CI）パイプラインに影響が及びます。
発表された計画とリリース済みのソフトウェアを区別することが重要です。RustはGit 2.xバージョンではオプトアウト可能なデフォルトでしたが、Git 3.0はまだリリースされていません。既存のリポジトリが自動的にSHA-256に変換されることはなく、この変更は新しく初期化されたリポジトリにのみ影響します。
Rustの要件にはプラットフォーム上のコストが伴う
Git 3.0ではコンパイルにRust toolchainが必須となり、これはメモリ安全性への懸念による変更です。Gitのセキュリティ脆弱性の大部分は、歴史的にC言語コードベースのメモリバグに起因しており、コアチームはRustコンポーネントの統合を進めています。
この要件はプラットフォームの互換性に関する課題をもたらします。Rustコンパイラおよび関連ツールチェーンは、現在Gitが正常にビルドできているすべてのレガシーまたはプロプライエタリなUnixプラットフォームをサポートしているわけではありません。近年のGit 2.xリリースではRustはオプトアウト可能なデフォルトでしたが、Git 3.0ではこの柔軟性が失われます。
直近の混乱を緩和するため、最終的なGit 2.xリリースには長期サポート（LTS）の延長が提供されます。この措置は、サポートされていないプラットフォームを使用するチームが、Gitインフラストラクチャの長期戦略を策定するための時間を確保することを目的としています。今後のアップグレードには互換性のあるビルド環境が必要となるためです。
なぜ64文字のハッシュがCI全体に波及するのか
Git 3.0ではオブジェクトIDが40文字から64文字の16進数に拡張され、SHA-1（160ビット）からSHA-256（256ビット）のハッシュへ移行します。この変更は暗号学的な衝突耐性を強化する一方で、既存のGitワークフローに対して多大な互換性の負債をもたらします。
何十万もの内部スクリプト、正規表現、CIキャッシュが、現在40文字のハッシュ長を前提としています。これらのシステムを更新するには組織全体で多大なエンジニアリングの労力が必要となり、以下に影響を与えます。
- CI/CDパイプライン
- Gitフック
- サードパーティツール
- 内部キャッシュメカニズム
リポジトリの相互運用性も別の課題です。SHA-256リポジトリは、特定のブリッジングメカニズムを実装しない限り、SHA-1リポジトリをサブモジュールとしてシームレスに統合できません。ホスティングプラットフォーム側も新しいハッシュ形式をサポートするようにインフラを更新する必要があり、さもなければユーザーは機能制限に直面することになります。
GitHubの共同創業者であるScott Chacon氏は、この移行を「世界的な悪夢」と表現し、実用的なセキュリティ上の利点はエコシステム全体にかかるコストと比較して最小限であると主張しています。彼は、Gitのセキュリティは単なる衝突耐性のあるハッシュではなく、分散型の信頼に根本的に依存しているという、Linus Torvalds氏が2005年に述べた主張を指摘しています。今後の変更に関する詳細は、BreakingChanges Documentation - Gitを参照してください。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
セキュリティをめぐる議論 — 今テストすべきこと
SHA-256への移行は、セキュリティ上の利点と移行コストをめぐる議論を巻き起こしています。GitHubの共同創業者であるScott Chacon氏は、実用的なセキュリティの向上は最小限であると主張し、Linus Torvalds氏が2005年に説明したGitのセキュリティモデルは、主に分散型の信頼とアクセス制御に依存していると述べています。Chacon氏は、リポジトリの認証情報の侵害やメンテナに対するソーシャルエンジニアリングの方が、暗号学的な衝突よりも低コストで成功確率の高い攻撃ベクトルであると示唆しています。
これに対しメンテナ側は、実証済みの衝突攻撃を含むSHA-1の既知の脆弱性を考慮すれば、危機に直面して強制的に対応させられる前に準備が必要であると反論しています。より強力なハッシュは、認証情報の侵害やソーシャルエンジニアリングの問題を解決するものではありませんが、暗号学的な整合性はリポジトリの信頼性において不可欠な要素であり続けています。GoogleのGitエンジニアは課題を認めつつも、SHA-1の衝突は今後容易になり、変更を遅らせれば業界が混乱に陥るだろうと警告しています。
開発者は現在、git init --object-format=sha256を使用してSHA-256の互換性をテストできます。このコマンドは、SHA-256形式で新しいリポジトリを初期化します。既存のリポジトリは自動的に変換されることはなく、SHA-1オブジェクト形式が維持されます。
テストでは以下に重点を置くべきです：
- CI（継続的インテグレーション）パイプライン
- 自動化スクリプト
- サブモジュールの取り扱い
- 新しいハッシュ長に対するホストシステムのサポート
これらの事前チェックにより、開発ツールチェーン全体における潜在的な破壊箇所を特定できます。
よくある質問
Git 3.0で予定されている主な変更点は何ですか？
Git 3.0では、ビルドにRustが必要となり、新しく初期化されるリポジトリのデフォルトのハッシュ形式がSHA-256になると予想されています。リリース日は未定です。
Git 3.0で既存のリポジトリはSHA-256に変換されますか？
いいえ。既存のリポジトリは現在のオブジェクト形式を維持します。予定されているSHA-256のデフォルト設定は、新しく初期化されるリポジトリにのみ適用されます。
今すぐSHA-256のGitリポジトリを試すにはどうすればよいですか？
ツールやホスティングプラットフォームの互換性の制限はありますが、git init --object-format=sha256を実行してSHA-256を使用するリポジトリを初期化してください。
なぜRustがGitのビルド要件になるのですか？
明言されている目的は、Gitにおけるメモリ安全性のリスクを軽減することです。その代償として、Rustツールチェーンをサポートしていない一部のプラットフォームでは、Git 3.0をビルドできなくなる可能性があります。