验证签名的git提交？

时间：2013-06-28 19:09:09

标签： git

使用较新版本的git，可以使用PGP密钥签署单独的提交（除标签外）：

git commit -m "some message" -S

您可以使用git log选项在--show-signature的输出中显示这些签名：

$ git log --show-signature
commit 93bd0a7529ef347f8dbca7efde43f7e99ab89515
gpg: Signature made Fri 28 Jun 2013 02:28:41 PM EDT using RSA key ID AC1964A8
gpg: Good signature from "Lars Kellogg-Stedman <lars@seas.harvard.edu>"
Author: Lars Kellogg-Stedman <lars@seas.harvard.edu>
Date:   Fri Jun 28 14:28:41 2013 -0400

    this is a test

但是有没有办法以编程方式验证给定提交上的签名，而不是通过grepping git log的输出？我正在寻找相当于git tag -v的提交 - 这将提供退出代码，指示给定提交中是否存在有效签名。

3 个答案:

答案 0 :(得分：76)

以防万一有人通过搜索引擎访问此页面，就像我一样：自问题发布以来的两年内已经提供了新工具：现在有git命令用于此任务：git verify-commit并且git verify-tag可以分别用于验证提交和标记。

答案 1 :(得分：23)

注意：最多git 2.5，git verify-commit和git verify-tag仅显示人类可读消息。
如果你想自动化检查，git 2.6 +（2015年第3季度）会增加另一个输出。

请参阅commit e18443e，commit aeff29d，commit ca194d5，commit 434060e，commit 8e98e5f，commit a4cc18f，commit d66aeff（2015年6月21日） brian m. carlson (bk2204) （由Junio C Hamano -- gitster --合并于commit ba12cb2，2015年8月3日）

  

verify-tag / verify-commit：添加打印原始gpg状态信息的选项

     默认情况下，

verify-tag / verify-commit会在标准错误上显示人类可读的输出   但是，访问原始gpg状态信息也很有用，这些信息是机器可读的，允许自动实施签名策略。

     

添加 --raw选项，使verify-tag生成标准错误的gpg状态信息，而不是人类可读的格式。

加：

  如果签名是好的，但关键是，

verify-tag会成功退出   不可信。 verify-commit退出失败。
  这种行为上的分歧是出乎意料的，也是不受欢迎的   由于之前存在verify-tag，因此请添加失败的测试，以便verify-commit分享verify-tag的行为。

git 2.9（2016年6月）更新git merge doc：

commit 05a5869见Keller Fuchs (``)（2016年5月13日） 帮助：Junio C Hamano (gitster)。
（2016年5月17日Junio C Hamano -- gitster -- commit be6ec17合并） 

--verify-signatures:
--no-verify-signatures:
  

验证正在合并的侧分支的提示提交是否使用有效密钥签名，即具有有效uid的密钥：在默认信任模型中，这意味着签名密钥已由可信任的密钥签名键。
  如果侧分支的提示提交未使用有效密钥签名，则合并将中止。

更新Git 2。10（2016年第3季度）

commit b624a3e见Linus Torvalds (torvalds)（2016年8月16日） （由Junio C Hamano -- gitster --合并于commit 83d9eb0，2016年8月19日）

  

gpg-interface：更喜欢＆＃34; long＆＃34;验证pgp签名时的密钥格式输出

     

＆＃34; git log --show-signature＆＃34;显示PGP签名验证状态的其他命令现在显示更长的key-id，因为32位key-id是上个世纪。

     

Linus的原创版本被重新引用以应用于维护轨道，以防万一过去陷入困境的二进制分销商希望将其带入旧代码库。

Git 2.11 +（2016年第4季度）甚至会更精确。

commit 661a180见Michael J Gruber (mjg)（2016年10月12日） （Junio C Hamano -- gitster --于2016年10月26日commit 56d268b合并）

  

＆＃34; %G?＆＃34;中显示的GPG验证状态漂亮的格式说明符不够丰富，无法区分过期密钥签名，撤销密钥签名等。
  已指定新的输出字母来表达。

     

根据gpg2's doc/DETAILS：

     
    

对于每个签名，只会发出一个代码GOODSIG，BADSIG，EXPSIG，EXPKEYSIG，REVKEYSIG或ERRSIG。

  

git pretty-format documentation现在包括：

  
      
  • ＆＃39; %G?＆＃39;：显示      
        
    • ＆＃34; G＆＃34;一个好的（有效的）签名，
      •   
    • ＆＃34; B＆＃34;签名不好，
      •   
    • ＆＃34; U＆＃34;对于有效性未知的好签名，
      •   
    • ＆＃34; X＆＃34;对于已经过期的好签名，
      •   
    • ＆＃34; Y＆＃34;对于过期密钥签名的好签名，
      •   
    • ＆＃34; R＆＃34;通过已撤销的密钥进行良好签名，
      •   
    • ＆＃34; E＆＃34;如果签名无法检查（例如丢失密钥）   和＆＃34; N＆＃34;没有签名
      •   
    •   

Git 2.12（2017年第1季度）＆＃34; git tag＆＃34;和＆＃34; git verify-tag＆＃34; 学会了将GPG验证状态放入＆＃34; --format=<placeholders>＆＃34;输出格式。

commit 4fea72f点击commit 02c5433，commit ff3c8c8，Santiago Torres (SantiagoTorres)（2017年1月17日）。{ commit 07d347c见commit 2111aa7，commit 94240b9，Lukas Puehringer (``)（2017年1月17日）。 （Junio C Hamano -- gitster --于2017年1月31日commit 237bdd9合并）

  

将--format添加到git tag -v会使GPG的默认输出静音   验证，而是打印格式化的标签对象   这允许调用者用refs / tags交叉检查标记名   GPG验证时标记对象标题中的标记名。

Git 2.16（2018年第一季度）将允许提交签名验证更加自动化，使用merge.verifySignatures配置变量。

commit 7f8ca20见commit ca779e8，Hans Jerry Illikainen (``)（2017年12月10日） （Junio C Hamano -- gitster --合并于commit 0433d53，2017年12月28日）

  

merge：为verifySignatures

添加配置选项      

git merge --verify-signatures可用于验证提示提交   正在合并的分支的正确签名，但它很麻烦   必须每次都指定。

     

添加一个默认启用此行为的配置选项   可以被--no-verify-signatures覆盖。

git merge config man page现在显示为：

merge.verifySignatures:
     

如果为true，则相当于--verify-signatures命令行选项。

Git 2。19（Q8 2018）更有帮助，因为＆＃34; git verify-tag＆＃34;和＆＃34; git verify-commit＆＃34;已被教导使用基础＆＃34; gpg --verify＆＃34;的退出状态。发现他们发现的不良或不可信的签名。

注意：使用Git 2.19，gpg.format that can be set to "openpgp" or "x509", and gpg.<format>.program that is used to specify what program to use to deal with the format) to allow x.509 certs with CMS via "gpgsm" to be used instead of openpgp via "gnupg".

commit 4e5dc9c见Junio C Hamano (gitster)（2018年8月9日） 帮助：Vojtech Myslivec (VojtechMyslivec)，brian m. carlson (bk2204)和Jeff King (peff) （由Junio C Hamano -- gitster --合并于commit 4d34122，2018年8月20日）

  

gpg-interface：将退出状态从gpg传播回来电

     

当gpg-interface API在2015年中左右统一支持签名标签和签名提交的签名验证代码路径时，大约在v2.6.0-rc0~114，我们意外地放松了GPG签名验证。

     

在此更改之前，通过查找来自GPG的＆＃34; G＆＃34; ood签名来验证已签名的提交，同时忽略＆＃34; gpg --verify＆＃34的退出状态;过程，通过简单地传递"gpg --verify＆＃34;的退出状态来验证已签名的标签通过。

     

我们目前的统一代码忽略了＆＃34; gpg --verify＆＃34;的退出状态。并且当签名与未到期密钥匹配时返回成功验证，无论对密钥的信任度如何（即除了＆＃34; G＆＃34; ood之外，我们接受＆＃34; {{1} }＆＃34; ntrusted ones）。

     

使这些命令在基础＆＃34; U＆＃34; （或由＆＃34; gpg --verify＆＃34;配置变量指定的自定义命令）这样做   这实际上以向后不兼容的方式改变了他们的行为，以拒绝使用不可信密钥进行的签名，即使他们正确验证，因为这是＆＃34; gpg.program＆＃34;的行为。

     

请注意，代码仍会覆盖从＆＃34; gpg --verify＆＃34;获得的零退出状态。 （或gpg）如果输出没有说签名是好的，或者是用不可信的密钥进行正确计算，那么要抓住一个写得不好的包装器＆＃34; gpg.program＆＃34;用户可以给我们。

     

我们可以从这个备用代码中排除＆＃34; gpg＆＃34; ntrusted支持，但这会在一次提交中进行两次向后不兼容的更改，所以现在让我们避免这种情况。
  如果需要，可以进行后续更改。

答案 2 :(得分：4)

粗略检查代码表明没有这样的直接方法。

git源中的所有测试都依赖于grep ping git show的输出（请参阅t/t7510-signed-commit.sh进行测试）。

您可以使用--pretty "%H %G?%"之类的内容自定义输出，以便于解析。

您似乎可以要求git merge验证签名，但同样，其测试依赖于grep（请参阅t/t7612-merge-verify-signatures.sh）。它看起来像一个无效的签名会导致git merge以错误的签名退出，所以你今天可能会通过在某处进行测试合并并抛弃合并来解决这个问题，但这似乎比调用grep更糟糕。< / p>

相关问题
最新问题