要約

書き換わるのは名前だけではない

一冊の本の内容を変えずに、別の方式で指紋を計算することはできる。Gitのblobなら、その説明はかなり近い。しかし書棚の目録には別の本の指紋が書かれている。Gitのツリーにはファイルや下位ツリーの名前が入り、コミットにはツリーと親コミットの名前が入る。タグも他のオブジェクトを指し得る。移行設計が説明する通り、参照先の名前を替えれば参照元のバイト列も変わり、参照元の名前まで再計算しなければならない。歴史全体が連鎖する。

そのため、新しいハッシュ方式を選ぶことと、既存の履歴を安全に渡すことは別の仕事だった。古いSHA-1の名前は保存済みリポジトリにも、遠隔のサーバーにも、周辺の道具にも残る。同じ対象が新方式ではどの名前になるかを追跡する対応表が要る。暗号学的に望ましい計算式を掲げても、昔の住所録は自動で書き換わらない。

2018年の文書は双方向の名前対応を提案し、リポジトリを一つずつ移しながらSHA-1サーバーともやり取りする目標を置いた。実装の段階も分け、初期設計には新しいプロトコル対応を含めなかった。これは完成の報告書ではなく、工事計画である。橋の図面を公開することは大事だが、それで貨物列車は渡れない。

2020年のスイッチと2026年の注意書き

Git 2.29.0のgit-initマニュアルには2020年時点で--object-format=sha256が登場する。同じ項目は実験的な機能として扱い、通常のSHA-1リポジトリとは一般に作業を共有できず、試験用途を想定すると警告した。新形式の箱を作る操作と、既存の倉庫網にその箱を流す操作は違う。

Git 2.54.0のマニュアルでは2026年にもsha1が既定で、sha256は選択肢だ。さらにSHA-1とSHA-256のリポジトリ間には現在相互運用性がないと記す。設計から八年、実験的な選択肢から六年が経っても、異なる形式の履歴を普通に交換するという一点は公式の説明で解決済みになっていない。

一方、GitのBreakingChanges文書はGit 3.0で新規リポジトリの既定をSHA-256にする計画を示す。公開日は定めず、ライブラリ、アプリケーション、ホスティング側の準備を条件にしている。SHA-1オブジェクト形式の廃止も現時点では計画していない。新しい入口の既定値を変えても、過去の履歴が同時に新しい形式へ引っ越すわけではない。

決定権は実装の外にもある

設計文書はSHA-1の弱点と2017年のSHAttered衝突を取り上げ、SHA-256を選ぶ理由を述べた。だがハッシュの安全性だけでは交換経路を開けない。クライアント、保存形式、サーバー、依存するアプリのどこかが新旧の名前を結び付けられなければ、協業の境界で止まる。Gitの開発者は方向を決められる。接続相手の更新を一つのコミットで済ませる権限はない。

この歴史が示すのは、名前がシステムの外側に貼られた飾りではないという事実だ。Gitでは名前がデータの中に入り、そのデータを別の道具が使う。新方式の発表は始まりにすぎない。動いているソフトウェアの集合が、移行の実際の日付を決める。