验证签名的git提交?

lar*_*sks 84 git

使用更新版本,git可以使用PGP密钥对单个提交(除标签外)进行签名:

git commit -m "some message" -S
Run Code Online (Sandbox Code Playgroud)

您可以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
Run Code Online (Sandbox Code Playgroud)

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

tar*_*leb 90

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

  • 我只想补充一点,如果这些命令返回空,则意味着该元素没有签名(标记或提交) (5认同)

Von*_*onC 27

注意:最多为git 2.5,git verify-commit并且git verify-tag只显示人类可读的消息.
如果你想自动检查,git 2.6+(2015年第3季度)增加了另一个输出.

请参阅brian m的提交e18443e,提交aeff29d,提交ca194d5,提交434060e,提交8e98e5f,提交a4cc18f,提交d66aeff(2015年6月21日).卡尔森(bk2204).
(由Junio C gitsterHamano合并- -提交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:

Keller Fuchs的承诺05a5869(2016年5月13日)(``).
帮助:Junio C Hamano(gitster).
(由Junio C gitsterHamano合并- -提交be6ec17,2016年5月17日)

--verify-signatures:
--no-verify-signatures:
Run Code Online (Sandbox Code Playgroud)

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


更新Git 2.10(2016年第3季度)

请参阅Linus Torvalds()提交b624a3e(2016年8月16日).(由Junio C Hamano合并- -提交83d9eb0,2016年8月19日)torvalds
gitster

gpg-interface:在验证pgp签名时,更喜欢"长"键格式输出

" git log --show-signature"和其他显示PGP签名验证状态的命令现在显示更长的key-id,因为32位key-id是上个世纪.

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


Git 2.11 +(2016年第4季度)甚至更精确.

请参阅Michael J Gruber()提交的661a180(2016年10月12日).(由Junio C Hamano合并- -提交56d268b,2016年10月26日)mjg
gitster

%G?"漂亮格式说明符"中显示的GPG验证状态不够丰富,无法区分由过期密钥创建的签名,由已撤销密钥生成的签名等.
已分配新输出字母来表达它们.

根据gpg2的doc/DETAILS说法:

每个签名只有代码之一GOODSIG,BADSIG,EXPSIG,EXPKEYSIG,REVKEYSIGERRSIG将被发射.

git pretty-format文档现在包括:

  • ' %G?':表演
    • " G"为了一个好的(有效的)签名,
    • " B"签名不好,
    • " U"对于有效性未知的好签名,
    • " X"对于已过期的好签名,
    • " Y"对于过期密钥所做的好签名,
    • " R"用于通过已撤销密钥进行的良好签名,
    • " E"如果签名无法检查(例如丢失密钥),则"N"无签名

Git 2.12(2017年第一季度)" git tag"和" git verify-tag" 学会了将GPG验证状态设置为" --format=<placeholders>"输出格式.

请参阅Santiago Torres()提交4fea72f,提交02c5433,提交ff3c8c8(2017年1月17日). 请参阅Lukas Puehringer的提交07d347c,提交2111aa7,提交94240b9(2017年1月17日)(``).(由Junio C Hamano合并- -提交237bdd9,2017年1月31日)SantiagoTorres

gitster

添加--formatgit tag -v静音GPG验证的默认输出,而是打印格式的标签对象.
这允许调用者在GPG验证时使用标记对象头中的标记名来交叉检查refs/tags中的标记名.


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

参见提交7f8ca20,提交ca779e8(2017年12月10日)作者:Hans Jerry Illikainen(``).
(由Junio C gitsterHamano合并- -0433d53提交,2017年12月28日)

merge:添加配置选项 verifySignatures

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

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

git merge配置手册页现为:

merge.verifySignatures:
Run Code Online (Sandbox Code Playgroud)

如果为true,则这相当于--verify-signatures命令行选项.


Git 2.19(Q8 2018)更有帮助,因为" git verify-tag"和" git verify-commit"已被教导使用底层" gpg --verify" 的退出状态来表示他们发现的不良或不可信签名.

注意:使用Git 2.19,gpg.format可以设置为" openpgp"或" x509",gpg.<format>.program用于指定用于处理格式的程序)以允许使用带有CMS的x.509证书gpgsm来代替openpgp通过" gnupg".

Junio C Hamano()提交4e5dc9c(2018年8月9日). 帮助:Vojtech Myslivec(),brian m.卡尔森()杰夫金().(由Junio C Hamano合并- -提交4d34122,2018年8月20日)gitster
VojtechMyslivecbk2204peff
gitster

gpg-interface:将退出状态从gpg返回传播给调用者

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

在更改之前,签名提交通过查找G来自GPG的" "签名进行验证,同时忽略" gpg --verify"进程的退出状态,而通过简单地传递"gpg --verify"通过" 的退出状态来验证签名的标签.

我们当前的统一代码忽略了" gpg --verify" 的退出状态,并且当签名与未到期的密钥匹配时返回成功的验证,而不管对密钥的信任(即除了" G"ood的,我们接受" U"ntrusted的密钥).

当基础" gpg --verify"(或" gpg.program"配置变量" 指定的自定义命令)这样做时,使这些命令以退出状态发出信号失败.
这实质上是以向后不兼容的方式改变它们的行为,以拒绝使用不可信密钥进行的签名,即使它们正确验证,因为这就是" gpg --verify"行为的方式.

请注意,代码仍然覆盖从" gpg"(或gpg.program)获得的零退出状态,如果输出没有说签名是好的或正确计算但是使用不可信密钥,则捕获一个写得不好的包装器" gpg"用户可能会给我们.

我们可以U从这个回退代码中排除" "不受信任的支持,但是这会在单个提交中进行两次向后不兼容的更改,所以现在让我们避免这种情况.
如果需要,可以进行后续更改.

  • 干得好,让这篇文章保持最新的变化,我花了很长时间才看到评论 (3认同)

Emi*_*Sit 5

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

git 源中的所有测试都依赖于grepping 的输出git show(有关测试,请参阅t/t7510-signed-commit.sh)。

您可以使用类似的方法自定义输出--pretty "%H %G?%"以使其易于解析。

看来您可以要求git merge验证签名,但同样,它的测试依赖于grep(参见t/t7612-merge-verify-signatures.sh)。看起来无效的签名会导致git merge以错误的签名退出,因此您今天可能会通过在某处进行测试合并并抛出该合并来解决此问题,但这似乎比仅调用 grep 更糟糕。