本文へ
ハクソク

世界を動かす技術を、日本語で。

Git 3.0のSHA-256デフォルトへの移行は高くつく誤りになるだろう

元記事: 原文(blog.gitbutler.com)

概要

  • Git 3.0で SHA-1からSHA-256 へのハッシュアルゴリズム変更が予定
  • この変更は 大規模な影響 を及ぼすが、実用的なメリットは少ない
  • セキュリティ上の問題は 理論的な脆弱性 に過ぎず、実際の攻撃は困難
  • 信頼性確保は ハッシュよりも流通経路や認証 が重要
  • 業界全体に 大きなコストと混乱 をもたらす可能性

Git 3.0のハッシュアルゴリズム変更がもたらす問題

  • Git 3.0で デフォルトのハッシュアルゴリズム がSHA-1からSHA-256に変更予定

  • SHA-1は 理論的に衝突が可能 となったが、実用的な攻撃例はほぼ皆無

  • SHA-1の衝突攻撃（SHAttered 2017, SHA-1 is a Shambles 2020）の存在

  • しかし、 偶然の衝突発生確率は極めて低い ため、現実的なリスクはほぼゼロ

  • SHA-256への移行は セキュリティ強化のため とされるが、実質的なメリットは限定的

    • Gitの信頼性は ハッシュ値自体より流通経路 や 認証 に依存
    • Linus Torvaldsも「 セキュリティは分散性にある」と主張
    • 実際の攻撃は ソーシャルエンジニアリング や 依存関係の乗っ取り が主流
    • ハッシュ衝突による攻撃は コスト・難易度が高く非現実的

衝突攻撃とセカンドプリイメージ攻撃の実態

  • 衝突攻撃： 同じハッシュ値を持つ2つの異なるファイル を用意し、信頼を得た後に悪意あるファイルへすり替え
  • セカンドプリイメージ攻撃： 既存ファイルのハッシュに一致する別の悪意あるファイル を作成し、すり替えを狙う手法
  • しかし、 どちらも現実的なGit運用では成立しにくい
    • MD5ですら プリイメージ攻撃は現実的に不可能
    • 実際のリスクは 流通経路の信頼性や署名検証 で十分対策可能

実際のリスクと運用現場の現状

  • Gitのハッシュ衝突攻撃より 依存パッケージの乗っ取りや権限の不正取得 の方がはるかに現実的
  • オープンソースプロジェクトの メンテナンス権限譲渡 や 認証情報の流出 が主な攻撃経路
  • ハッシュアルゴリズムの強化よりも 流通経路の管理や署名付きコミット、 信頼できるリポジトリ利用 が重要

SHA-256移行のコストと今後の懸念

  • SHA-256移行は ツール・エコシステム全体の大規模な変更 を伴う
  • 移行により 互換性問題や運用コスト増大 が予想される
  • 「 理論的脆弱性発見→全体移行」のループに陥るリスク
  • ハッシュの強度と 信頼性の本質的な混同 が問題の根本

結論：本当に必要な対策とは

  • Gitの信頼性は ハッシュアルゴリズムの強度 よりも 流通経路・認証・署名 に依存
  • SHA-1からSHA-256への移行は コストに見合った効果が薄い
  • 実運用でのセキュリティ強化は 運用・認証・署名の徹底 が最優先
  • 理論的な脆弱性だけで 大規模な移行を正当化するのは再考の余地
  • 今後も 本質的な信頼性向上策 に目を向ける必要

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

読んだところによると、gitのSHA256はIPv6の再来のように見える。特に以下の点が気になるね：

  • 後方互換性がない実装になってる
  • 古いモデルに対する利点がちょっと曖昧
  • 追いつかなきゃいけないツールがたくさんあって、動きがあまり見えない
└
  • 古いモデルに対する利点がちょっと曖昧 これはIPv6に関しては全然違うよ！
└

今、上からの圧力で安全なソフトウェア供給チェーンを作る動きがすごい。GoogleのSBOMやSigStoreとか。これは自然なニーズじゃないけど、政府のお客さんがいると選択肢があまりないんだよね。

└

IPv6の採用との違いは、インターネットがネットワーク効果に大きく依存していることだね。いくつかのホストがIPv4アドレスしか持っていない限り、完全な接続にはIPv4アドレスが必要だけど、みんながIPv4アドレスを持っているなら、IPv6に移行する必要はすぐにはない。 （そう、Hacker Newsのユーザーは自己ホスティングやピアツーピアネットワークなど、IPv6の使い道がたくさんあるから、平均的なユーザーとは違うんだ。）この効果はGitの移行には存在しない。各リポジトリは独立して更新できるし、他のリポジトリのユーザーには影響しない。おそらく、ほとんどの開発者はSHA-1のリポジトリとSHA-256のリポジトリの両方で問題なく作業するだろうね。むしろ、Python 2からPython 3への移行と比較できると思う。あれも痛かったけど、結局成功したし（最初からそれほど必要ではなかったけど）。

GitがSHA-1とSHA-256のモードをもっと互換性を持たせないのが理解できない。SHA1でハッシュされたオブジェクトはSHA-256でハッシュされたオブジェクトを参照できるべきだけど、なんか無意味な気もする。でもSHA-256でハッシュされたオブジェクトもSHA1でハッシュされたオブジェクトを参照できるべきだよ、ただし大きな注意点がある。もしそのオブジェクトが衝突ペアの一部だったら、実際に問題が起こる。でもこれを避けることはできる！例えば、LinuxがSHA-256に移行することを決めたとする。その場合、上流プロジェクトは、2027年1月1日と2027年3月1日という日付を選ぶことができる。最初の日付までに、メンテナーはまだリポジトリにないけど後で提出するかもしれないオブジェクトのハッシュを提出できるし、その日付に上流ツリーがこれらのオブジェクトのリストを確定してリポジトリに参照を追加する（そのための新しいメカニズムを使って）。2日目からは、リポジトリはSHA-256のコミットを公開し、カットオフ日以降にリポジトリにないSHA1でハッシュされたオブジェクトは受け付けなくなる。そして新しいSHA1の衝突をリポジトリに入れることは不可能になる。必要な新しいgitの機能は以下の通り： a) SHA-256でハッシュされたオブジェクトがSHA1でハッシュされたオブジェクトを参照できる実際の互換性 b) SHA-256でハッシュされたリスト（おそらくそれらのツリー）の新しいオブジェクトタイプを作成し、コミットからこれにリンクするメカニズム c) 事前に設定されたSHA-256でハッシュされたコミットから到達可能なSHA1でハッシュされたオブジェクトだけを許可するポリシーメカニズム

└

エミリーのトークは、ハッシュを混ぜることの問題をうまくまとめてるよね。

└

うーん、でもコミットの日付はコミットの中に保存されてるよね。コミットの日付が本物かどうかを知る唯一の方法は、そのハッシュを通じてなんだ。もし私が自由にSHA1ハッシュを偽造できるなら、torvaldsのリポジトリのヘッドコミットと同じSHA1を持つリポジトリを作れるし、そこでは悪意のあるコミットが同じSHA1と偽の日付で置き換えられてる。深い履歴の比較以外に、私のリポジトリが本物じゃないことを検出する方法はないよ。マークルツリーの考え方は、トップのハッシュをチェックするだけで全体のアイデンティティがわかるってことなんだ。解決策が何かはわからないけど、単一のSHA1コミットを持つリポジトリは、すべてSHA1コミットのリポジトリと同じくらい脆弱だと思う。

これって、リポジトリを移行すると、「commitを見てください」というテキストが含まれるすべてのコミットメッセージが壊れちゃうってことだよね。これは大惨事になる。互換性モードを追加する前にリリースしないでほしいな。

└

git-filter-repoのようなツールは、コミットメッセージ内のコミットハッシュを書き換えることをサポートしているよ。実際、git-filter-repoはデフォルトでそれをやってる。マニュアルの--preserve-commit-hashesを見てみて。

└

SHA-1はすでに壊れているから（GPU時間的には高コストだけど）、テキスト「commitを参照してください」もすでに壊れているね。

└

これが実際に痛みを伴うようになったら、各自で置き換えインデックス作成者を使うことになるだろうね（gitはすでに置き換えオブジェクトをサポートしてるし）。パックとオブジェクトのインデックス作成において、双方向の変換ができるようにするために。パフォーマンスとメモリ使用に大きなダメージが出るけど、まあ仕方ないか。そして、公式バージョンを待つことになるね。

└

SHA1をデータベースに残す計画はあるみたいだけど、私の知る限り、送信する方法はないから、個別のフォージに特化しているようだね。再計算はできるけど、署名が壊れちゃうし、実際に置き換えがあった場合、再計算が間違っている可能性もあるから、比較が簡単じゃない。じゃあ、何の意味があるの？

Hacker Newsで議論の続きを見る

同じ出典の記事