As part of implementing signature verification for git clone, I decided to refactor/unify the code for commit and merge verification to make it reusable during clones. This lead me to discover that git requires merge signatures to be trusted (as opposed to TRUST_UNKNOWN or TRUST_NEVER). This is unlike the behavior of verify-tag and verify-commit. So, I figured that I'd make the minimum trust level configurable to make the behavior of merge/commit/tag consistent. And while doing so, I noticed that parse_gpg_output() in gpg-interface.c assumes that the VALIDSIG status line has a field with a fingerprint for the primary key; but that is only the case for OpenPGP signatures [1]. The consequence of that assumption is that the subsequent status line is interpreted as the primary fingerprint for X509 signatures. I'm not sure if the order is hardcoded in GnuPG, but in my testing the TRUST_ status line always came after VALIDSIG -- and that breaks the config option to set a minimum trust level (not part of this patch): ,---- | $ git log -n1 --format="primary key: %GP" signed-x509 | gpgsm: Signature made 2019-11-16 14:13:09 using certificate ID 0xFA23FD65 | gpgsm: Good signature from "/CN=C O Mitter/O=Example/SN=C O/GN=Mitter" | gpgsm: aka "committer@xxxxxxxxxxx" | primary key: TRUST_FULLY 0 shell `---- [1]: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/DETAILS Hans Jerry Illikainen (1): gpg-interface: limit search for primary key fingerprint gpg-interface.c | 20 +++++++++++++++----- t/t4202-log.sh | 6 ++++++ 2 files changed, 21 insertions(+), 5 deletions(-) -- 2.24.0.156.g69483321b9.dirty
