Rya*_*n J 18 git x509certificate trusted-timestamp rfc3161
我已经将我正在使用的脚本发布到StackExchange Code Review站点.
我原来的问题是,有没有办法可以使用X.509证书和时间戳签署Git提交？.有一段时间我以为我只能用我的X.509证书签署的东西,我的X.509证书由一个受信任的第三方加盖时间戳.不是这种情况.使用X.509证书和可信时间戳进行数字签名是互斥的.我已更新我的问题以反映这一点.
正如VonC所指出的那样,使用X.509证书签署Git提交不会增加任何价值.由于Git内置支持,使用GPG密钥是一个更好的选择.
我已经接受了格雷格的回答,因为它与我要求的最接近,即使我原来的问题有点含糊不清.正如Greg指出的那样,如果你能证明你在某个时间点知道提交哈希,那么这可以保证你知道当时哈希所用的存储库内容,并且不需要在存储库中存储任何额外的数据.时间戳数据可以存储在任何地方.
可以使用openssl(v1.0.0 +)并curl为提交哈希请求RFC3161时间戳.
你需要有一些信息:
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.如果时间戳服务拒绝请求,它也可能输出错误.
这与请求时间戳非常相似,但您还需要:
时间戳服务应该使用由受信任的颁发机构颁发的证书签署时间戳.如果没有,你的时间戳没有太大的可信度.如果找不到或创建正确的证书链,请尝试使用cacert.pem发布的curl.就在这里.
以下代码段假定正在传递现有的签名时间戳回复stdin.应该可以将上述请求直接传递给下面的verify命令.如果将请求中的响应存储在变量中,则可能需要对其进行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提交何时发生以及我的存储库的历史记录尚未重写.它不一定是每次提交.每天一次或每周一次就足够了.有推荐的方法吗？
我知道我可以使用GPG密钥签署Git提交,但我想知道是否有办法可以使用X.509证书签署我的提交,并使用http://timestamp.comodoca等在线时间戳服务.com/rfc3161.
如果没有,将git rev-parse --verify HEAD每天一次将当前版本转储到文本文件中,签署该文件,并提交足以证明(大致)我的代码编写时间？
为Clarity添加了Info
我知道Git保证了存储库的完整性,但据我所知,如果我控制存储库,第三方就必须相信我没有重新编写存储库的历史记录或者将时钟推回原点.创建了一个完全虚假的存储库,只是为了'证明'我的代码比实际更旧？我也不想公开发布我的存储库.
这是一个虚构的用例,可以更好地了解我想要做的事情.
我在网上发布了一些代码.一年后,有人在书籍或文章中复制并发布相同的代码,并声称我是复制它们的人.那时,我希望能够获取我的存储库并证明我在一年前提交了该代码,然后才重新发布它.
通过使用带有时间戳服务的X.509证书,我可以证明签名何时发生.只要我能证明我知道一年前提交的哈希值,Git就会保证存档的完整性.
或者,有没有办法使用GPG密钥签署提交,但有一个经过验证的时间戳？是否有可靠的第三方提供类似于X.509证书的时间戳服务,但对于GPG？
也许我可以使用GPG密钥和X.509证书的组合.假设我在存储库中保留了我的(公共)GPG密钥的副本,如果我在每天结束时执行此操作,是否会进行以下操作？
您所要做的就是公开发布SHA1(提交ID).如果您愿意,可以使用该SHA1并使用您的X.509证书(使用适当的时间戳服务)对其进行签名并保留它.如果有人质疑您的作者身份,您可以轻松地在生成特定SHA1的特定时间显示您知道存储库的内容.你并不需要任何实际签名存储里面的代码库.