署名されたgitタグはどの程度安全ですか？ SHA-1と同じくらい安全か、それともなんとか安全か？
署名されたgitタグはどの程度安全ですか？特にgitはSHA-1を使用しているためです。周辺には矛盾する情報があります。
したがって、gitタグ（git tag -v tagname）、タグをchecksouts、そしてgit status追跡されていない/変更されたファイルを報告せず、さらに手動でコードを監査しない限り、これは実際にどの程度安全ですか？ SHA-1と同じくらい安全ですか？
SHA-1の衝突を引き起こすことができる敵を想定しましょう。
GitはセキュリティではなくSHA-1を使用します
そして続く。
セキュリティパーツは別の場所にあります
これについて詳しく説明してもらえますか？セキュリティパーツはどこにありますか？これらがどのように機能するかを簡単に説明できますか？これについてどこでもっと読むことができますか？
それにもかかわらず、SHA-1の2番目のプリイメージ耐性がないと、署名とコミットはマークルツリーのルートにのみ署名するため、リポジトリの状態を保護できなくなります。
これは、Linus Torvaldsの発言と矛盾します。それはセキュリティにとって何を意味しますか？どちらが正しいですか？
出典：
ソース管理システムのGitは、セキュリティではなく、偶発的な破損によってデータが変更されないようにするためにSHA-1を使用します。 Linus Torvalds氏は、「ディスクが破損している場合、DRAMが破損している場合、なんらかの問題がある場合は、Gitがそれらに気づきます。問題ではないことは保証されます。悪意のあるものであり、成功することはありません。[...] SHA-1を破ることができる人はいませんが、Gitに関する限り、SHA-1はセキュリティ機能でさえありません。純粋に整合性チェックです。セキュリティの部分は別の場所にあるため、多くの人はGitがSHA-1を使用し、SHA-1は暗号的に安全なものに使用されているため、OK、それは巨大なセキュリティ機能だと思います。セキュリティとの関係では、それはあなたが得ることができる最高のハッシュです。[...]データをGitに入れれば、5年後にハードから変換されたという事実を信頼できます5年後、ディスクからDVDに新しいテクノロジーをコピーしてコピーし、5年後に、取得したデータが、入力したデータとまったく同じであることを確認できます。[...] One o私が気にする理由がカーネルである場合、BitKeeperサイトの1つに侵入して、カーネルソースコードリポジトリを破損させようとしました。」
更新：
A Git Horror Story：Signed Commits with Repository Integrity With Signed Commits の著者であるMike Gerwitzから詳細な回答を得ました。
https://forums.whonix.org/t/security-git-general-verification-verifying-whonix-submodules/513/12
矛盾はありません。ライナス自身 同じ話で言った ：
これらの20バイトがあれば、完全に信頼されていないソースからgitリポジトリをダウンロードでき、彼らが何か悪いことをしていないことを保証できます。
「GitはセキュリティのためではなくSHA-1を使用している」と解釈します。「SHA-1はセキュリティ上の理由からgitに追加されていませんが、信頼性上の理由からしかし、セキュリティは依然として素晴らしい副作用です = "、および「セキュリティ部分は別の場所にあります」「最終検証はgpgによって行われ、git verify-tag "。
GitコミットIDは、「ベア」SHA-1よりも「安全」ではありません。ただし、gitを使用するユースケースは、他のほとんどのSHA-1ユースケースよりも衝突攻撃に対してより耐性があります。
たとえば、証明書のSHA-1は危険です。誰かが同じハッシュで異なるドメイン名の2つの証明書を作成する可能性があります。 1つ（「正当な」1つ）はCSRでCAに送信され、もう1つはCAからの署名を持つ被害者に使用されるまで非公開にされます。衝突攻撃では、攻撃者がプレイメージをある部分（証明書のドメイン名フィールドなど）で変更した場合、別の場所でも変更する必要があります。攻撃者は2つのドメイン名を自由に選択できましたが、その他の変更はほとんど修正されています。特に、これらはバイナリであり、人間が読める証明書の一部にすることはできません。一部の攻撃は、証明書の公開/秘密鍵にそれらを隠します（ MD5のディスカッション ）。
ただし、Gitは主にソースコードに使用されます。 ASCII人間がレビューしたdiffで{chosen-prefix、}の衝突を隠すことははるかに困難です。通常、メンテナは16進アドレスについてif条件を作成するときに質問します2ff5eファイルのlogo.pngコミットに追加しました。まとめると、SHA-1を攻撃するよりも、コミット内にバックドアを隠す方が簡単です。
署名付きのgitタグは、署名付きのSHA1チェックサムです。非常に簡単に言うと、すべてのgitコミットは、以前のコミットのSHA1チェックサムです（これには、以前のコミットのSHA1チェックサムも含まれる以前のコミットのSHA1も含まれています...）。
方法を見つけた場合、リポジトリ内の何かを変更し、SHA1を変更せずに維持する（衝突を見つける）場合、署名を破ることができます。
Gitは分散VCSであることを覚えておいてください。通常、自分のクローンを持っている人はたくさんいます。何か問題があった場合、すぐに発見されます。
また、衝突の検出と特定の衝突の検出には大きな違いがあります。たとえば、同じMD5合計で2つの「ランダムな」異なるデータを見つけるのは簡単です。しかし、私の知る限り、特定のデータをわずかに変更してMD5を変更しない方法は依然として難しい問題であり、SHA1はMD5よりもはるかに強力です。
それでも、SHA1の衝突を簡単に見つける方法を誰かが見つけたとしたら、gitの方がはるかに大きな問題になるでしょう。 GitはすべてのオブジェクトインデックスとしてSHA1を使用します。 SHA1で衝突したオブジェクトをコミットしようとすると、おそらくコミットが失敗します（...わかりません...）。
以下は私の理解です。
Gitはほとんどすべてをsha1ハッシュで識別します。署名されたタグは、sha1ハッシュによってコミットを参照します。コミットは、sha1ハッシュによって「ツリー」を識別し、「ツリー」は、sha1ハッシュによってファイル「ブロブ」を参照します。
したがって、同じsha1ハッシュを持つ「blobs」で表される2つのファイルがある場合、一方を他方に置き換えることができ、署名付きタグは引き続き正常に検証されます。
オブジェクトのgitハッシュでは、ヘッダーの前にタイプとサイズが付加されます。つまり、gitを攻撃するために使用される衝突は、gitを攻撃するために特別に準備する必要がありますが、それ以上の問題は発生しません。
実際には、リスクはあなたがGitリポジトリに何を保持しているかに大きく依存すると思います。 SHA1のプリイメージ攻撃はありません。すぐに攻撃を受ける可能性はほとんどありません。したがって、衝突攻撃のみを心配する必要があります。
それが人間のレビュー担当者によってレビューされた人間が読めるソースコードである場合、リスクは小さいです。誰かが原因不明のバイナリガベージのブロックとそのバイナリガベージのブロックのコンテンツに基づいて悪意のあることを行う条件付きブロックに侵入できた場合、sha1の衝突を気にすることなく、悪意のあるものに侵入する可能性があります。
OTOHが信頼できないソースからのバイナリを格納するために使用されている場合、問題が発生する可能性が高くなります。
「すぐに時間があるとは思えない」-うーん。 「攻撃は良くなるだけだ」。
プリイメージ攻撃は、衝突攻撃よりもはるかに困難です。最初の衝突がMD5で実証されてから10年が経過しても、実行可能なプリイメージ攻撃はまだありません。
「jpeg + innocent code」と「jpeg + evil code」を含む2つのコミットについてもっと心配するでしょう
複雑さは、gitコミットがjpegデータを構造化する方法が原因であり、コードは同じファイルになければなりません。 gitリポジトリなどにtarballを保存している場合は問題になると思います。
別の可能なシナリオは、いくつかのコードが自動ファイルタイプ検出に基づいてファイルをどうするかを決定した場合です。 「明確に選択された接頭辞」の衝突が実用的になると、誰かがたまたまゴミをどこかに持っている無害に見えるバイナリファイル（画像など）をコミットする可能性があります。次に、それをより危険なファイルに置き換えます。
Md5と比較すると、基本的な衝突から明確に選択されたプレフィックスの衝突に至るまでに約2年かかりました。