【ITニュース解説】Git SHA-256 migration: what the Git 3 proposal actually changes

Gitは、ソフトウェア開発におけるバージョン管理システムとして広く使われているツールである。ソースコードの変更履歴を効率的に管理し、複数人での共同開発を可能にする。このGitにおいて、現在、重要な技術的変更が提案されており、それが「GitのSHA-256移行」である。この提案は、新規に作成されるリポジトリのデフォルトのハッシュアルゴリズムを、現在のSHA-1からより強力なSHA-256に切り替えることを主眼としている。この変更は、セキュリティの強化を目的としているが、その影響範囲や具体的な移行方法については議論が続いている。

まず、ハッシュアルゴリズムとは何か、なぜGitにとって重要なのかを理解する必要がある。Gitは、管理するファイルの内容やディレクトリの構造、そしてコミットといったすべてのオブジェクトを、特定のハッシュアルゴリズムで計算された一意の識別子（ハッシュ値）によって管理している。このハッシュ値は、データの内容が少しでも変更されると全く異なる値になるため、データの改ざんがないことを保証する役割も果たす。現在のGitは「SHA-1」というハッシュアルゴリズムを使用しており、これにより各オブジェクトは40桁の英数字のハッシュ値で識別されている。

提案されている「Git 3.0」の変更は、新規リポジトリを作成する際に、このオブジェクトの識別に使われるハッシュアルゴリズムのデフォルトを「SHA-256」に変更するというものである。SHA-256はSHA-1よりも長く、より複雑なハッシュ値を生成するため、セキュリティが向上すると考えられている。この変更が実現すれば、新規に作成されるGitリポジトリのオブジェクトは、64桁の英数字のハッシュ値で識別されるようになる。

しかし、この変更は単にハッシュ値の桁数が増えるという単純な話ではない。Gitの内部では、コミットがツリーを参照し、ツリーがブロブ（ファイル内容）や他のツリーを参照するといった形で、すべてのオブジェクトがハッシュ値によって相互に連結されている。もしハッシュアルゴリズムが変更されれば、これらのオブジェクトの識別子が一斉に変わってしまうため、その変更はリポジトリの履歴全体に波及する。例えば、過去のコミットが参照しているツリーやブロブのハッシュ値も変わるため、その参照関係を維持するためには、関連するすべてのハッシュ値を更新する必要がある。

この大規模な変更に対して、一部から懸念の声が上がっている。特に、GitHubとGitButlerの共同創設者であるScott Chacon氏は、この計画を「費用のかかる間違い」と表現し、強く批判している。彼の主張は、Gitの既存のオブジェクト識別子、つまり40桁のSHA-1ハッシュ値に依存して開発されてきた膨大な数のツールやサービスが、この変更によって大規模な改修作業を強いられる可能性があるという点にある。多くのツールは、ハッシュ値の桁数を40桁と固定して扱っていたり、ハッシュ値に基づいたリンクや署名処理を行っていたりするため、SHA-256への移行は単なるコードの書き換え以上の影響を及ぼす可能性がある。

このセキュリティ強化の背景には、SHA-1ハッシュアルゴリズムの脆弱性が指摘されてきたという歴史がある。2017年には「SHAttered」と呼ばれる衝突攻撃が成功し、2020年には「SHA-1 is a Shambles」という研究で、さらに進んだ衝突攻撃が実証された。これらの攻撃は、異なるデータから同じSHA-1ハッシュ値を生成してしまう可能性を示すもので、データの改ざんを見抜けなくなる危険性を示唆している。Gitプロジェクトは、これらの既知の攻撃に対して、既に「強化されたSHA-1」（hardened SHA-1）を使用することで対策を講じている。しかし、将来的な未知の攻撃に備えるため、より強力なハッシュアルゴリズムであるSHA-256への移行を目指しているのである。Chacon氏は、この追加のセキュリティ向上のために支払うコストが高すぎると考え、オブジェクトアドレッシング（オブジェクトの識別）と、署名されたオブジェクトに含めるツリーコンテンツの強力なハッシュを分離するという別の提案をしている。

実際のところ、現在のGitのバージョンでは、SHA-1とSHA-256のリポジトリ間には互換性がない。筆者が行ったローカルでの検証では、Git 2.34.1を用いて、SHA-1形式のリポジトリからSHA-256形式のリポジトリへのデータ取得（フェッチ）を試みたところ、エラーが発生し、両者のアルゴリズムが一致しないことが示された。これは、Git 3.0がリリースされたとしても、既存のSHA-1リポジトリと新しいSHA-256リポジトリの間で、何も手を加えずに直接やり取りすることはできないことを示唆している。

一方で、GitHubでは、既にSHA-256のオブジェクト名を持つ一部の公開プレビューリポジトリが存在することが確認されている。筆者がGitHubの特定のプレビューリポジトリに対してgit ls-remoteコマンドを実行したところ、64桁のSHA-256形式のハッシュ値が返された。これは、GitHubが限定的ながらもSHA-256への対応を進めていることを示す。しかし、これは読み取り専用の機能であり、新規リポジトリの作成や書き込み操作が一般的にサポートされていることを意味するものではない。

システムエンジニアを目指す初心者がこの状況で理解すべきことは、Gitのこの変更が将来的に開発環境に影響を及ぼす可能性があるということである。特に、チームが新規プロジェクトでSHA-256形式のリポジトリを使用することを検討する際には、慎重な準備が必要となる。まず、プロジェクトで使用するすべてのツール、例えばエディタのGit統合、CI/CDパイプラインで使用するライブラリ、そしてコードホスティングサービスが、SHA-256形式のリポジトリをサポートしているかを確認する必要がある。

具体的には、社内のスクリプトや自動化ツールの中に、Gitのハッシュ値が常に40桁であることを前提とした記述がないかを確認することが重要である。また、Gitのオブジェクト識別子をデータベースに保存したり、それらの識別子を使って他のシステムと連携したりしている場合、それらのシステムも新しい64桁のハッシュ値に対応できるかどうかの検証が不可欠となる。もし、署名（コミットやタグへの署名など）を使用している場合は、その署名処理が新しいハッシュ形式に対応しているか、公式の移行設計で示されているマッピングや署名の目標と合致しているかを比較する必要がある。これらの確認は、「動けば良い」という安易な考えではなく、実際のツールバージョン、テストした操作、そして観察された失敗を記録として残すことで、将来的な問題発生時の対応に役立つ。

このGitのSHA-256移行は、新規リポジトリのデフォルト変更であり、既存のSHA-1リポジトリは引き続きサポートされる予定である。そのため、既存のプロジェクトがすぐに影響を受けるわけではない。しかし、将来的にプロジェクトを始める際には、この新しいデフォルトと、それに伴うエコシステムの準備状況を考慮に入れる必要がある。この提案は、エコシステムの準備が整うことを条件としているため、「準備が整う」とは具体的に何をするべきなのか、自分のチームにとって何が必要なのかを検証することが、今後の重要な課題となるだろう。セキュリティの向上は重要だが、それと引き換えに既存のツールチェーンが機能しなくなるような事態は避けるべきであり、互換性を確保しながらセキュリティ強化を進めるバランスが求められている。