验证签名的 git 提交？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/17371955/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Verifying signed git commits?
提问by larsks
With newer versions of gitit's possible to sign individual commits (in addition to tags) with a PGP key:
对于较新版本，git可以使用 PGP 密钥对单个提交（除了标签）进行签名：
git commit -m "some message" -S
And you can show these signatures in the output of git logwith the --show-signatureoption:
您可以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 <[email protected]>"
Author: Lars Kellogg-Stedman <[email protected]>
Date: Fri Jun 28 14:28:41 2013 -0400
this is a test
But is there a way to programatically verify the signature on a given commit other than by grepping the output of git log? I'm looking for the commit equivalent of git tag -v-- something that will provide an exit code indicating whether or not there was a valid signature on a given commit.
但是有没有办法以编程方式验证给定提交上的签名，而不是通过 grepping 的输出git log？我正在寻找相当于git tag -v--的提交，它将提供一个退出代码，指示给定提交是否存在有效签名。
回答by tarleb
Just in case someone comes to this page through a search engine, like I did: New tools have been made available in the two years since the question was posted: There are now git commands for this task: git verify-commitand git verify-tagcan be used to verify commits and tags, respectively.
以防万一有人像我一样通过搜索引擎访问此页面：自问题发布以来的两年内已经提供了新工具：现在有用于此任务的 git 命令：git verify-commit并且git verify-tag可以用于验证提交和标签，分别。
回答by VonC
Note: up to git 2.5, git verify-commitand git verify-tagonly displayed a human readable message.
If you want to automate the check, git 2.6+ (Q3 2015) adds another output.
注意：直到 git 2.5，git verify-commit并且git verify-tag只显示人类可读的消息。
如果你想自动化检查，git 2.6+ (Q3 2015) 添加了另一个输出。
See commit e18443e, commit aeff29d, commit ca194d5, commit 434060e, commit 8e98e5f, commit a4cc18f, commit d66aeff(21 Jun 2015) by brian m. carlson (bk2204).
(Merged by Junio C Hamano -- gitster--in commit ba12cb2, 03 Aug 2015)
请参阅brian m 的commit e18443e、commit aeff29d、commit ca194d5、commit 434060e、commit 8e98e5f、commit a4cc18f、commit d66aeff（2015 年 6 月 21 日）。卡尔森 ( bk2204)。
（由Junio C gitsterHamano合并-- --在ba12cb2 提交中，2015 年 8 月 3 日）
verify-tag/verify-commit: add option to print raw gpg status information
verify-tag/verify-commitby default displays human-readable output on standard error.
However, it can also be useful to get access to the raw gpg status information, which is machine-readable, allowing automated implementation of signing policy.Add a
--rawoptionto makeverify-tagproduce the gpg status information on standard error instead of the human-readable format.
verify-tag/verify-commit: 添加打印原始 gpg 状态信息的选项
verify-tag/verify-commit默认情况下在标准错误上显示人类可读的输出。
但是，访问原始 gpg 状态信息也很有用，该信息是机器可读的，允许自动实施签名策略。添加一个
--raw选项来verify-tag生成关于标准错误的 gpg 状态信息，而不是人类可读的格式。
Plus:
加：
verify-tagexits successfully if the signature is good but the key is untrusted.verify-commitexits unsuccessfully.
This divergence in behavior is unexpected and unwanted.
Sinceverify-tagexisted earlier, add a failing test to haveverify-commitshareverify-tag's behavior.
verify-tag如果签名良好但密钥不受信任，则成功退出。verify-commit退出失败。
这种行为上的分歧是出乎意料和不受欢迎的。
由于verify-tag较早存在，添加一个失败的测试以获取verify-commitshareverify-tag的行为。
git 2.9 (June 2016) update the git merge doc:
git 2.9（2016 年 6 月）更新git merge 文档：
See commit 05a5869(13 May 2016) by Keller Fuchs (``).
Helped-by: Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster--in commit be6ec17, 17 May 2016)
请参阅Keller Fuchs (``) 的提交 05a5869（2016 年 5 月 13 日）。
帮助者：Junio C Hamano ( gitster)。
（由Junio C gitsterHamano合并-- --在提交 be6ec17，2016 年 5 月 17 日）
--verify-signatures:
--no-verify-signatures:
Verify that the tip commit of the side branch being merged is signed with a valid key, i.e. a key that has a valid uid: in the default trust model, this means the signing key has been signed by a trusted key.
If the tip commit of the side branch is not signed with a valid key, the merge is aborted.
验证正在合并的侧分支的提示提交是否使用有效密钥签名，即具有有效 uid 的密钥：在默认信任模型中，这意味着签名密钥已由受信任的密钥签名。
如果侧分支的提示提交未使用有效密钥签名，则合并中止。
Update Git 2.10 (Q3 2016)
更新 Git 2.10（2016 年第三季度）
See commit b624a3e(16 Aug 2016) by Linus Torvalds (torvalds).
(Merged by Junio C Hamano -- gitster--in commit 83d9eb0, 19 Aug 2016)
请参阅Linus Torvalds ( ) 的提交 b624a3e（2016 年 8 月 16 日）。（由Junio C Hamano合并-- --在83d9eb0 提交中，2016 年 8 月 19 日）torvaldsgitster
gpg-interface: prefer "long" key format output when verifying pgp signatures"
git log --show-signature" and other commands that display the verification status of PGP signature now shows the longer key-id, as 32-bit key-id is so last century.Linus's original was rebased to apply to the maintenance track just in case binary distributors that are stuck in the past want to take it to their older codebase.
gpg-interface: 验证 pgp 签名时更喜欢“长”密钥格式输出"
git log --show-signature"和其他显示 PGP 签名验证状态的命令现在显示更长的 key-id，因为 32 位 key-id 是上世纪的。Linus 的原始版本被重新定位以适用于维护轨道，以防万一过去陷入困境的二进制分发者想要将其带到他们的旧代码库中。
Git 2.11+ (Q4 2016) will even be more precise.
Git 2.11+（2016 年第四季度）甚至会更加精确。
See commit 661a180(12 Oct 2016) by Michael J Gruber (mjg).
(Merged by Junio C Hamano -- gitster--in commit 56d268b, 26 Oct 2016)
请参阅Michael J Gruber ( ) 的commit 661a180（2016 年 10 月 12 日）。（由Junio C Hamano合并-- --在提交 56d268b 中，2016 年 10 月 26 日）mjggitster
The GPG verification status shown in "
%G?" pretty format specifier was not rich enough to differentiate a signature made by an expired key, a signature made by a revoked key, etc.
New output letters have been assigned to express them.According to gpg2's
doc/DETAILS:For each signature only one of the codes
GOODSIG,BADSIG,EXPSIG,EXPKEYSIG,REVKEYSIGorERRSIGwill be emitted.
“
%G?”中显示的 GPG 验证状态漂亮格式说明符不够丰富，无法区分由过期密钥生成的签名、由撤销密钥生成的签名等。
已分配新的输出字母来表示它们。每个签名只有代码之一
GOODSIG，BADSIG，EXPSIG，EXPKEYSIG，REVKEYSIG或ERRSIG将被发射。
The git pretty-formatdocumentationnow include:
该git pretty-format文档现在包括：
- '
%G?': show
- "
G" for a good (valid) signature,- "
B" for a bad signature,- "
U" for a good signature with unknown validity,- "
X" for a good signature that has expired,- "
Y" for a good signature made by an expired key,- "
R" for a good signature made by a revoked key,- "
E" if the signature cannot be checked (e.g. missing key) and "N" for no signature
- '
%G?': 显示
- "
G" 一个好的（有效的）签名，- "
B"对于一个不好的签名，- “
U”对于一个未知有效性的好签名，- “
X”对于已过期的好签名，- “
Y”对于由过期密钥生成的良好签名，- “
R”对于由已撤销的密钥生成的良好签名，- "
E" 如果无法检查签名（例如丢失的密钥）和 "N" 表示没有签名
Git 2.12 (Q1 2017) "git tag" and "git verify-tag" learned to put GPG verification status in their "--format=<placeholders>" output format.
Git 2.12（2017 年第一季度）“ git tag”和“ git verify-tag”学会了将 GPG 验证状态放在它们的“ --format=<placeholders>”输出格式中。
See commit 4fea72f, commit 02c5433, commit ff3c8c8(17 Jan 2017) by Santiago Torres (SantiagoTorres).
See commit 07d347c, commit 2111aa7, commit 94240b9(17 Jan 2017) by Lukas Puehringer (``).
(Merged by Junio C Hamano -- gitster--in commit 237bdd9, 31 Jan 2017)
请参阅圣地亚哥托雷斯 ( ) 的提交 4fea72f、提交 02c5433、提交 ff3c8c8(2017 年 1 月 17 日)。
请参阅Lukas Puehringer (``) 的commit 07d347c、commit 2111aa7、commit 94240b9（2017 年 1 月 17 日）。（由Junio C Hamano合并-- --在commit 237bdd9，2017 年 1 月 31 日）SantiagoTorresgitster
Adding
--formattogit tag -vmutes the default output of the GPG verification and instead prints the formatted tag object.
This allows callers to cross-check the tagname from refs/tags with the tagname from the tag object header upon GPG verification.
添加
--format到git tag -v静音 GPG 验证的默认输出，而是打印格式化的标签对象。
这允许调用者在 GPG 验证时交叉检查来自 refs/tags 的标记名与来自标记对象标头的标记名。
Git 2.16 (Q1 2018) will allow the commit signature verification to be even more automated, with the merge.verifySignaturesconfiguration variable.
Git 2.16（2018 年第一季度）将允许提交签名验证更加自动化，使用merge.verifySignatures配置变量。
See commit 7f8ca20, commit ca779e8(10 Dec 2017) by Hans Jerry Illikainen (``).
(Merged by Junio C Hamano -- gitster--in commit 0433d53, 28 Dec 2017)
请参阅Hans Jerry Illikainen (``) 的commit 7f8ca20和commit ca779e8（2017 年 12 月 10 日）。
（由Junio C gitsterHamano合并-- --在提交 0433d53，2017 年 12 月 28 日）
merge: add config option forverifySignatures
git merge --verify-signaturescan be used to verify that the tip commit of the branch being merged in is properly signed, but it's cumbersome to have to specify that every time.Add a configuration option that enables this behaviour by default, which can be overridden by
--no-verify-signatures.
merge: 添加配置选项verifySignatures
git merge --verify-signatures可用于验证被合并的分支的提示提交是否正确签名，但每次都必须指定它很麻烦。添加一个默认启用此行为的配置选项，它可以被
--no-verify-signatures.
The git mergeconfig man pagenow reads:
该git merge配置手册页现为：
merge.verifySignatures:If true, this is equivalent to the
--verify-signaturescommand line option.
merge.verifySignatures:如果为 true，则这等效于
--verify-signatures命令行选项。
Git 2.19 (Q3 2018) is even more helpful, since "git verify-tag" and "git verify-commit" have been taught to use the exit status of underlying "gpg --verify" to signal bad or untrusted signature they found.
Git 2.19（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”。
See commit 4e5dc9c(09 Aug 2018) by Junio C Hamano (gitster).
Helped-by: Vojtech Myslivec (VojtechMyslivec), brian m. carlson (bk2204), and Jeff King (peff).
(Merged by Junio C Hamano -- gitster--in commit 4d34122, 20 Aug 2018)
请参阅Junio C Hamano() 的commit 4e5dc9c（2018 年 8 月 9 日）。
帮助者：Vojtech Myslivec ( ), brian m. 卡尔森（）和杰夫金（）。（由Junio C Hamano合并-- --在commit 4d34122，2018 年 8 月 20 日）gitsterVojtechMyslivecbk2204peffgitster
gpg-interface: propagate exit status fromgpgback to the callersWhen gpg-interface API unified support for signature verification codepaths for signed tags and signed commits in mid 2015 at around v2.6.0-rc0~114, we accidentally loosened the GPG signature verification.
Before that change, signed commits were verified by looking for "
G"ood signature from GPG, while ignoring the exit status of "gpg --verify" process, while signed tags were verified by simply passing the exit status of"gpg --verify" through.The unified code we currently have ignores the exit status of "
gpg --verify" and returns successful verification when the signature matches an unexpired key regardless of the trust placed on the key (i.e. in addition to "G"ood ones, we accept "U"ntrusted ones).Make these commands signal failure with their exit status when underlying "
gpg --verify" (or the custom command specified by "gpg.program" configuration variable) does so.
This essentially changes their behaviour in a backward incompatible way to reject signatures that have been made with untrusted keys even if they correctly verify, as that is how "gpg --verify" behaves.Note that the code still overrides a zero exit status obtained from "
gpg" (orgpg.program) if the output does not say the signature is good or computes correctly but made with untrusted keys, to catch a poorly written wrapper around "gpg" the user may give us.We could exclude "
U"ntrusted support from this fallback code, but that would be making two backward incompatible changes in a single commit, so let's avoid that for now.
A follow-up change could do so if desired.
gpg-interface: 将退出状态从gpg后面传播给调用者当 gpg-interface API 在 2015 年年中 v2.6.0-rc0~114 左右统一支持签名标签和签名提交的签名验证代码路径时，我们不小心放松了 GPG 签名验证。
在此更改之前，签名提交是通过
G从 GPG查找“ ood 签名”来验证的，而忽略“gpg --verify”进程的退出状态，而签名标签是通过简单地传递"gpg --verify“通过”的退出状态来验证的。统一代码，我们目前有忽略的退出状态“
gpg --verify”和返回时的签名未到期的关键，无论放置在关键的信任匹配成功验证（即除“G‘OOD的，我们接受’U” ntrusted的）。当底层“
gpg --verify”（或“gpg.program”配置变量指定的自定义命令）这样做时，使这些命令以其退出状态发出失败信号。
这从本质上以一种向后不兼容的方式改变了他们的行为，以拒绝使用不受信任的密钥制作的签名，即使他们正确验证，因为这就是“gpg --verify”的行为方式。请注意，如果输出未表明签名良好或计算正确但使用不受信任的密钥生成，则代码仍会覆盖从“
gpg”（或gpg.program）获得的零退出状态，以捕获gpg用户可能给我们的“ ”周围写得不好的包装器.我们可以
U从这个回退代码中排除“ ”ntrusted 支持，但这会在一次提交中产生两个向后不兼容的更改，所以现在让我们避免这种情况。
如果需要，可以进行后续更改。
the key is needed to be trusted/signed before do any encryption
在进行任何加密之前，需要信任/签署密钥
On the trust side, there is progress:
With Git 2.26 (Q1 2020), gpg.minTrustLevelconfiguration variable has been introduced to tell various signature verification codepaths the required minimum trust level.
在信任方面，有进展：
在 Git 2.26（2020 年第一季度）中，gpg.minTrustLevel引入了配置变量来告诉各种签名验证代码路径所需的最低信任级别。
See commit 54887b4(27 Dec 2019) by Hans Jerry Illikainen (illikainen).
(Merged by Junio C Hamano -- gitster--in commit 11ad30b, 30 Jan 2020)
请参阅Hans Jerry Illikainen ( ) 的提交 54887b4（2019 年 12 月 27 日）。（由Junio C Hamano合并-- --在commit 11ad30b，2020 年 1 月 30 日）illikainengitster
gpg-interface: add minTrustLevel as a configuration optionSigned-off-by: Hans Jerry Illikainen
Previously, signature verification for merge and pull operations checked if the key had a trust-level of either
TRUST_NEVERorTRUST_UNDEFINEDinverify_merge_signature().If that was the case, the process
die()'d.The other code paths that did signature verification relied entirely on the return code from
check_commit_signature().And signatures made with a good key, irregardless of its trust level, was considered valid by
check_commit_signature().This difference in behavior might induce users to erroneously assume that the trust level of a key in their keyring is always considered by Git, even for operations where it is not (e.g. during a
verify-commitorverify-tag).The way it worked was by
gpg-interface.cstoring the result from the key/signature status andthe lowest-two trust levels in theresultmember of thesignature_checkstructure (the last of these status lines that were encountered got written toresult).These are documented in GPG under the subsection
General status codesandKey related, respectively.The GPG documentation says the following on the
TRUST_ statuscodes:These are several similar status codes:
- TRUST_UNDEFINED <error_token> - TRUST_NEVER <error_token> - TRUST_MARGINAL [0 [<validation_model>]] - TRUST_FULLY [0 [<validation_model>]] - TRUST_ULTIMATE [0 [<validation_model>]]For good signatures one of these status lines are emitted to indicate the validity of the key used to create the signature.
The error token values are currently only emitted by gpgsm.My interpretation is that the trust level is conceptually different from the validity of the key and/or signature.
That seems to also have been the assumption of the old code in
check_signature()where a result of 'G' (as inGOODSIG) and 'U' (as inTRUST_NEVERorTRUST_UNDEFINED)were both considered a success.The two cases where a result of '
U' had special meaning were inverify_merge_signature()(where this causedgittodie()) and informat_commit_one()(where it affected the output of the%G?format specifier).I think it makes sense to refactor the processing of
TRUST_ statuslines such that users can configure a minimum trust level that is enforced globally, rather than have individual parts ofgit(e.g. merge) do it themselves (except for a grace period with backward compatibility).I also think it makes sense to not store the trust level in the same struct member as the key/signature status.
While the presence of a
TRUST_ statuscode does imply that the signature is good (see the first paragraph in the included snippet above), as far as I can tell, the order of the status lines from GPG isn't well-defined; thus it would seem plausible that the trust level could be overwritten with the key/signature status if they were stored in the same member of thesignature_checkstructure.This patch introduces a new configuration option:
gpg.minTrustLevel.It consolidates trust-level verification to
gpg-interface.cand adds a newtrust_levelmember to thesignature_checkstructure.Backward-compatibility is maintained by introducing a special case in
verify_merge_signature()such that if no user-configurablegpg.minTrustLevelis set, then the old behavior of rejectingTRUST_UNDEFINEDandTRUST_NEVERis enforced.If, on the other hand,
gpg.minTrustLevelis set, then that value overrides the old behavior.Similarly, the
%G?format specifier will continue show 'U' for signatures made with a key that has a trust level ofTRUST_UNDEFINEDorTRUST_NEVER,even though the 'U' character no longer exist in theresultmember of thesignature_checkstructure.A new format specifier,
%GT, is also introduced for users that want to show all possible trust levels for a signature.Another approach would have been to simply drop the trust-level requirement in
verify_merge_signature().This would also have made the behavior consistent with other parts of git that perform signature verification.
However, requiring a minimum trust level for signing keys does seem to have a real-world use-case.
For example, the build system used by the Qubes OS project currently parses the raw output from verify-tag in order to assert a minimum trust level for keys used to sign git tags.
gpg-interface: 添加 minTrustLevel 作为配置选项签字人：Hans Jerry Illikainen
以前，合并和拉取操作的签名验证会检查密钥的信任级别是否为
TRUST_NEVER或TRUST_UNDEFINEDinverify_merge_signature()。如果是这样的话，进程
die()'d。其他进行签名验证的代码路径完全依赖于
check_commit_signature().并且无论其信任级别如何，使用好密钥生成的签名都被 认为是有效的
check_commit_signature()。这种行为上的差异可能会导致用户错误地认为 Git 始终会考虑其密钥环中密钥的信任级别，即使对于不考虑的操作（例如在 a
verify-commit或期间verify-tag）。它的工作方式是
gpg-interface.c将密钥/签名状态的结果和结构result成员中最低的两个信任级别signature_check（遇到的这些状态行中的最后一个写入result）。这些分别记录在 GPG 小节
General status codes和下Key related。GPG 文档对
TRUST_ status代码有以下说明：这些是几个类似的状态代码：
- TRUST_UNDEFINED <error_token> - TRUST_NEVER <error_token> - TRUST_MARGINAL [0 [<validation_model>]] - TRUST_FULLY [0 [<validation_model>]] - TRUST_ULTIMATE [0 [<validation_model>]]对于好的签名，发出这些状态行之一以指示用于创建签名的密钥的有效性。
错误标记值目前仅由 gpgsm 发出。我的解释是信任级别在概念上不同于密钥和/或签名的有效性。
这似乎也是旧代码的假设，
check_signature()其中 'G'（如GOODSIG）和 'U'（如TRUST_NEVER或TRUST_UNDEFINED)都被认为是成功的。在两种情况下的“结果
U”有特殊的含义是在verify_merge_signature()（其中这引起了git到die()），并在format_commit_one()（它影响到的输出%G?格式说明）。我认为重构行的处理是有意义的，
TRUST_ status这样用户可以配置全局强制执行的最低信任级别，而不是让git（例如合并）的各个部分自己做（具有向后兼容性的宽限期除外）。我还认为不将信任级别存储在与密钥/签名状态相同的结构成员中是有意义的。
虽然
TRUST_ status代码的存在确实意味着签名是好的（请参阅上面包含的代码段中的第一段），但据我所知，来自 GPG 的状态行的顺序没有明确定义；因此，如果密钥/签名状态存储在signature_check结构的同一成员中，那么信任级别可能会被密钥/签名状态覆盖，这似乎是合理的。此补丁引入了一个新的配置选项：
gpg.minTrustLevel.它将信任级别验证整合到结构中并向结构
gpg-interface.c添加新trust_level成员signature_check。向后兼容性是通过引入一种特殊情况来保持的
verify_merge_signature()，如果没有gpg.minTrustLevel设置用户可配置，则拒绝TRUST_UNDEFINED和TRUST_NEVER强制执行旧行为。另一方面，如果
gpg.minTrustLevel已设置，则该值会覆盖旧行为。同样，
%G?格式说明符将继续显示 'U' 用于使用信任级别为TRUST_UNDEFINED或TRUST_NEVER,即使 'U' 字符不再存在于结构result成员中的密钥生成的签名signature_check。
%GT还为想要显示签名的所有可能信任级别的用户引入了新的格式说明符 。另一种方法是简单地删除
verify_merge_signature().这也会使行为与执行签名验证的 git 其他部分保持一致。
但是，需要最低信任级别来签署密钥似乎确实有实际用例。
例如，Qubes OS 项目使用的构建系统当前解析来自 verify-tag 的原始输出，以便为用于签署 git tags 的密钥断言最低信任级别。
The git config gpgman pagenow includes:
该git config gpg手册页现在包括：
gpg.minTrustLevel:
Specifies a minimum trust level for signature verification.
If this option is unset, then signature verification for merge operations require a key with at leastmarginaltrust.
Other operations that perform signature verification require a key with at leastundefinedtrust.
Setting this option overrides the required trust-level for all operations. Supported values, in increasing order of significance:
undefinednevermarginalfullyultimate
gpg.minTrustLevel：
指定签名验证的最低信任级别。
如果未设置此选项，则合并操作的签名验证需要至少具有marginal信任的密钥。
执行签名验证的其他操作需要至少具有undefined信任的密钥。
设置此选项会覆盖所有操作所需的信任级别。支持的值，按重要性升序排列：
undefinednevermarginalfullyultimate
With Git 2.26 (Q1 2020), "git show" and others gave an object name in raw format in its error output, which has been corrected to give it in hex.
在Git 2.26 (Q1 2020) 中，" git show" 和其他人在其错误输出中以原始格式给出了一个对象名称，该名称已被更正为以十六进制给出。
show_one_mergetag: print non-parent in hex form.
When a mergetag names a non-parent, which can occur after a shallow clone, its hash was previously printed as raw data.
Print it in hex form instead.
show_one_mergetag：以十六进制形式打印非父项。
当合并标签命名一个非父对象时，这可能发生在一个浅克隆之后，它的哈希值以前被打印为原始数据。
改为以十六进制形式打印它。
Tested with git -C shallow log --graph --show-signature -n1 plain-shallowafter a git clone --depth 1 --no-local . shallow
git -C shallow log --graph --show-signature -n1 plain-shallow经过一段时间的测试git clone --depth 1 --no-local . shallow
With Git 2.27 (Q2 2020), the code to interface with GnuPG has been refactored.
在 Git 2.27（2020 年第二季度）中，与 GnuPG 交互的代码已经过重构。
See commit 6794898, commit f1e3df3(04 Mar 2020) by Hans Jerry Illikainen (illikainen).
(Merged by Junio C Hamano -- gitster--in commit fa82be9, 27 Mar 2020)
见提交 6794898，提交 f1e3df3（2020 年 3 月 4 日）由Hans Jerry Illikainen ( illikainen)。
（由Junio C gitsterHamano合并-- --在fa82be9 提交中，2020 年 3 月 27 日）
gpg-interface: prefercheck_signature()for GPG verificationSigned-off-by: Hans Jerry Illikainen
This commit refactors the use of
verify_signed_buffer()outside ofgpg-interface.cto usecheck_signature()instead.It also turns
verify_signed_buffer()into a file-local function since it's now only invoked internally bycheck_signature().There were previously two globally scoped functions used in different parts of Git to perform GPG signature verification:
verify_signed_buffer()andcheck_signature().Now only
check_signature()is used.The
verify_signed_buffer()function doesn't guard against duplicate signatures as described by Micha? Górny.Instead it only ensures a non-erroneous exit code from GPG and the presence of at least one
GOODSIGstatus field.This stands in contrast with
check_signature()that returns an error if more than one signature is encountered.The lower degree of verification makes the use of
verify_signed_buffer()problematic if callers don't parse and validate the various parts of the GPG status message themselves.And processing these messages seems like a task that should be reserved to
gpg-interface.cwith the functioncheck_signature().Furthermore, the use of
verify_signed_buffer()makes it difficult to introduce new functionality that relies on the content of the GPG status lines.Now all operations that does signature verification share a single entry point to
gpg-interface.c.This makes it easier to propagate changed or additional functionality in GPG signature verification to all parts of Git, without having odd edge-cases that don't perform the same degree of verification.
gpg-interface: 更喜欢check_signature()GPG 验证签字人：Hans Jerry Illikainen
此提交重构了使用
verify_signed_buffer()external ofgpg-interface.cto usecheck_signature()。它也变成
verify_signed_buffer()了一个文件本地函数，因为它现在只由check_signature().以前在 Git 的不同部分使用了两个全局作用域函数来执行 GPG 签名验证：
verify_signed_buffer()和check_signature().现在只
check_signature()用了。该
verify_signed_buffer()函数不能防止Micha 描述的重复签名？戈尔尼。相反，它仅确保来自 GPG 的无错误退出代码和至少一个
GOODSIG状态字段的存在。这与
check_signature()如果遇到多个签名则返回错误相反。
verify_signed_buffer()如果调用者自己不解析和验证 GPG 状态消息的各个部分，那么较低的验证程度会使使用出现问题。处理这些消息似乎是一项应该留给
gpg-interface.c函数的任务check_signature()。此外，使用
verify_signed_buffer()使得难以引入依赖于 GPG 状态行内容的新功能。现在，所有进行签名验证的操作都共享一个到
gpg-interface.c.这使得将 GPG 签名验证中更改的或附加的功能传播到 Git 的所有部分变得更加容易，而不会出现不执行相同程度验证的奇怪边缘情况。
回答by Emil Sit
A cursory inspection of the code suggests that there is no such direct method.
对代码的粗略检查表明没有这种直接的方法。
All of the tests in the git source rely on grepping the output of git show(see t/t7510-signed-commit.shfor the tests).
git 源中的所有测试都依赖于grepping 的输出git show（有关测试，请参阅t/t7510-signed-commit.sh）。
You can customize the output using something like --pretty "%H %G?%"to make it easy to parse.
您可以使用类似的方法自定义输出--pretty "%H %G?%"以使其易于解析。
It appears you can ask git mergeto verify a signature but again, its tests rely on grep(see t/t7612-merge-verify-signatures.sh). It does look like an invalid signature will cause git mergeto exit with a bad signature, so you could potentially today hack around this by doing a test merge somewhere and throwing out that merge but that seems worse than just calling grep.
看来您可以要求git merge验证签名，但同样，它的测试依赖于grep（参见t/t7612-merge-verify-signatures.sh）。看起来无效签名确实会导致git merge以错误签名退出，因此您今天可能会通过在某处进行测试合并并抛出该合并来解决此问题，但这似乎比仅调用 grep 更糟糕。
