20

更新しました

これに使用しているスクリプトを StackExchange Code Review サイトに投稿しました。

これに対する私の最初の質問は、X.509 証明書とタイムスタンプを使用して Git コミットに署名できる方法はありますか? でした。. しばらくの間、信頼できるサードパーティによってタイムスタンプが付けられた X.509 証明書で署名したものしか取得できないと思っていました。これはそうではありません。X.509 証明書によるデジタル署名と信頼できるタイム スタンプは、相互に排他的です。これを反映するために質問を更新しました。

VonC が指摘したように、Git コミットに X.509 証明書で署名しても何の価値もありません。Git にはサポートが組み込まれているため、GPG キーを使用する方がはるかに優れたオプションです。

元の質問は少しあいまいでしたが、それが私が求めていたものに最も近いため、Greg の回答を受け入れました。Greg が指摘しているように、特定の時点でのコミット ハッシュを知っていることを証明できれば、その時点でのハッシュの対象となるリポジトリ コンテンツを知っていることが保証され、リポジトリに余分なデータを保存する必要はありません。タイムスタンプ データはどこにでも保存できます。

openssl(v1.0.0+)を使用しcurlて、コミット ハッシュの RFC3161 タイムスタンプを要求することができます。

タイムスタンプをリクエストする

これには少しの情報が必要です。

  • URL - RFC3161 タイムスタンプ サービス
  • REV - タイムスタンプが必要なリビジョン (ハッシュ)。完全なハッシュである必要があります。
CONTENT_TYPE="Content-Type: application/timestamp-query"
ACCEPT_TYPE="Accept: application/timestamp-reply"

openssl ts -query -cert -digest "$REV" -sha1 \
    | curl -s -H "$CONTENT_TYPE" -H "$ACCEPT_TYPE" --data-binary @- $URL

上記は、署名されたタイムスタンプを に出力しstdoutます。タイムスタンプ サービスが要求を拒否した場合にも、エラーが出力されることがあります。

タイムスタンプを確認する

これはタイムスタンプのリクエストと非常に似ていますが、以下も必要です。

  • CAFILE - タイムスタンプ サービスからルート CA に戻る証明書チェーン

タイムスタンプ サービスは、信頼できる機関によって発行された証明書を使用してタイムスタンプに署名する必要があります。そうでない場合、タイムスタンプの信頼性は高くありません。適切な証明書チェーンが見つからない、または作成できない場合は、cacert.pem発行元を使用してみてくださいcurl。ここです

以下のスニペットは、署名付きの既存のタイムスタンプ応答が に渡されることを前提としていstdinます。上記のリクエストを以下の検証コマンドに直接パイプできるはずです。リクエストからのレスポンスを変数に格納する場合、base64 でエンコード / デコードする必要がある場合があります ( man base64)。

openssl ts -verify -digest "$REV" -in /dev/stdin -CAfile "$CAFILE"

返信を調べると、リクエスト ダイジェストが使用された Git リビジョンと一致することがわかります。このコマンドを使用して、返信のプレーン テキスト バージョンを調べることができます。

openssl ts -reply -in /dev/stdin -text

これは、Git リビジョンを先頭に追加した返信の例です。

--------------------------------------------------------------------------------
Revision: 871d715e5c072b1fbfacecc986f678214fa0b585
--------------------------------------------------------------------------------
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: 1.3.6.1.4.1.6449.2.1.1
Hash Algorithm: sha1
Message data:
    0000 - 87 1d 71 5e 5c 07 2b 1f-bf ac ec c9 86 f6 78 21   ..q^\.+.......x!
    0010 - 4f a0 b5 85                                       O...
Serial number: 0xB2EA9485C1AFF55C6FFEDC0491F257C8393DB5DC
Time stamp: Aug 15 08:41:48 2012 GMT
Accuracy: unspecified
Ordering: no
Nonce: 0x615F0BF6FCBBFE23
TSA: DirName:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO Time Stamping Signer
Extensions:

その他の注意事項

多くのタイム スタンプ サービスでは、スクリプト化された署名要求に遅延を追加するようユーザーに求めます。使用する予定のサービスで必要かどうかを確認してください。これを書いている時点で、私が使用している Comodo は、スクリプト化されたリクエストの間に 15 秒の遅延を要求します。Comodo を使用することを選択した唯一の理由は、コード署名証明書を購入したからです。

Git ノートは、署名付きのタイムスタンプの返信を保存するための当然の選択肢のように思えますが、投稿するための完全なソリューションはまだありません。私は現時点でこれにこだわっています。

私の元の質問と更新は以下のとおりです。


Git のコミットがいつ行われているか、およびリポジトリの履歴が書き換えられていないことを証明できるようにしたいと考えています。すべてのコミットである必要はありません。1日1回でも週1回でも十分です。そうするための推奨される方法はありますか?

GPG キーで Git コミットに署名できることはわかっていますが、X.509 証明書とhttp://timestamp.comodocaのようなオンライン タイムスタンプ サービスを使用してコミットに署名できる方法があるかどうか疑問に思っています。 .com/rfc3161

そうでない場合、現在のリビジョンをgit rev-parse --verify HEAD1 日 1 回テキスト ファイルにダンプし、そのファイルに署名し、コミットするだけで、コードがいつ書かれたかを (大まかに) 証明できますか?

明確にするために追加された情報

Git がリポジトリの完全性を保証していることは知っていますが、私が理解している限りでは、もし私がリポジトリを管理しているとしたら、サード パーティは、私がリポジトリの履歴を書き直したり、時計を遅らせたりしていないことを信頼しなければなりません。私のコードが実際よりも古いことを「証明」するためだけに、完全に偽のリポジトリを作成しましたか? また、リポジトリを公開したくありません。

これは、私がやりたいことをよりよく理解できる架空の使用例です。

いくつかのコードをオンラインで公開しています。1 年後、誰かが同じコードを本や記事にコピーして公開し、私がそれらをコピーしたと主張します。その時点で、私は自分のレポジトリを取得して、再公開される前に、そのコードを 1 年前にコミットしたことを証明したいと考えています。

X.509 証明書とタイムスタンプ サービスを使用することで、署名がいつ行われたかを証明できます。1 年前のコミットのハッシュを知っていることを証明できる限り、Git はアーカイブの整合性を保証します。

または、GPG キーを使用してコミットに署名する方法はありますが、タイムスタンプが検証されていますか? X.509 証明書で利用できるものと同様のタイムスタンプ サービスを提供する信頼できるサード パーティはありますか?

GPG キーと X.509 証明書の組み合わせを使用できるかもしれません。(公開) GPG キーのコピーをリポジトリに保持していると仮定すると、毎日の終わりに次の作業を行った場合、次のように動作しますか?

  1. X.509 証明書とオンライン タイムスタンプ サービスを使用して、(公開) GPG キーに署名します。
  2. (プライベート) GPG キーからの署名を使用して、変更をリポジトリにコミットします。
4

5 に答える 5

7

必要なのは、SHA1 (コミット ID) を公開することだけです。必要に応じて、その SHA1 を使用して X.509 証明書で署名し (適切なタイムスタンプ サービスを使用)、そのままにしておくことができます。誰かがあなたの作成者に異議を唱えた場合、その特定の SHA1 を生成した特定の時点でのリポジトリの内容を知っていたことを簡単に示すことができます。実際にコード リポジトリに署名を保存する必要はありません。

于 2012-08-17T08:30:10.740 に答える
3

タイムスタンプ付きの証明書を最新のコミットに追加するだけです。sha1 は、証明書が変更されていないことを確認し、証明書自体が、信頼されたサーバーからの日付とタイム スタンプなど、それが主張するすべての「事実」、およびあなたが主張する人物などを検証します。つまり、Linus のスピーチからの VonC の引用に従って、コミットは証明書に署名します ;-)


[編集]明らかに、その新しいコミットのsha1を公開する必要があります。そうしないと、それ(および証明書)を修正し、新しいsha1を使用して、その新しいコミットの履歴にあるものを主張できます。いつものように、相互信頼のウェブを作成しています。

于 2012-08-11T22:09:05.883 に答える
1

Linus はその特定の機能を念頭に置いて Git を作成したため、私は私がフォローしているわけではありません (つまり、あなたが入れているものの完全性がまさに出てくるものです) 。

Google での 2007 年のスピーチ(トランスクリプト)を参照してください。

それらのほとんどは、試してみることさえせずに捨てることができました。

  • 配布されていない場合、使用する価値はありません。単純なことです。
  • パフォーマンスが悪い場合は、使用する価値がありません。それは簡単です。
  • また、SCM に入力した内容がまったく同じになることを保証できない場合は、使用する価値がありません

率直に言って、それはそこにあるすべてのことをほとんど処理しました.

SCM システムから得られるものが、入れたものと同じであることを保証しない SCM システムはたくさんあります

唯一の方法は、ファイルをチェックアウトしたときにファイルが破損していることに気付くことです。そして、ソース管理システムはあなたをまったく保護しません。
そして、これは珍しいことではありません。それは非常に一般的です。.

したがって、別の整合性機能を追加しても価値が高まるとは思いません。
また、「タイムスタンプ」も、そもそも DVCS 用に記録されていないため、正確には良い考えではありません (「Git: 元の作成/変更されたタイムスタンプを使用して古いファイルをチェックアウトするおよび「git のコミット時間を使用しますか? ")

于 2012-08-11T20:03:48.270 に答える