| Message ID | 20191216153204.8906-1-hji@dyntopia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | gpg-interface: add minTrustLevel as a configuration option | expand |
Hans Jerry Illikainen <hji@dyntopia.com> writes: > I think it makes sense to refactor the processing of TRUST_ status lines > such that users can configure a minimum trust level that is enforced > globally, rather than have individual parts of git (e.g. merge) do it > themselves. OK. > 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_ status code 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 the > signature_check structure. I agree that this is a good move---ever since gpg-interface.c was written, I have found it disturbing that the order of the lines in the output can affect the result we store and return to our callers > This patch introduces a new configuration option: gpg.minTrustLevel. It > consolidates trust-level verification to gpg-interface.c and adds a new > `trust_level` member to the signature_check structure. Nice. > Unfortunately, it breaks backward-compatibility in two ways: > > 1. The default trust level is TRUST_UNDEFINED. This is compatible with > the old behavior of every code path *except* for > verify_merge_signature() (since, again, it used to die()s on trust > levels below TRUST_MARGINAL). This might be a bit problematic. If we can keep the default behaviour identical to the code before this patch, while allowing the configuration to tweak the behaviour, that would have been more easily acceptable. That is, can we rearrange this patch so that each user of the verification code define its default minimum trust level (and verify-merge-signature would have a bit higher standard than everybody else), so that the uneven trust requirement is kept by default? And when the user explicitly sets the gpg.minTrustLevel configuration, these uneven default would all set to the given value. Later when the code gets a bit more mature, we would declare that we'd break the backward compatibility and set the default trust level for all codepaths even (either by raising everybody to marginal-or-better, or lowering everybody to undefined). > 2. The %G? format specifier no longer includes 'U' for signatures made > with a key that is either TRUST_UNDEFINED or TRUST_NEVER. Hmm, I can sort-of-see why you want to introduce a new placeholder "%GT" to disambiguate two sources of 'U', but why would this change to "%G?" necessary? > Instead, a > new %GT format specifier is introduced that outputs the trust level > (as a complete string to avoid ambiguity with TRUST_UNDEFINED and > TRUST_ULTIMATE).
On Mon, Dec 16 2019, Junio C Hamano wrote: >> Unfortunately, it breaks backward-compatibility in two ways: >> >> 1. The default trust level is TRUST_UNDEFINED. This is compatible with >> the old behavior of every code path *except* for >> verify_merge_signature() (since, again, it used to die()s on trust >> levels below TRUST_MARGINAL). > > This might be a bit problematic. If we can keep the default > behaviour identical to the code before this patch, while allowing > the configuration to tweak the behaviour, that would have been > more easily acceptable. Done in v1. >> 2. The %G? format specifier no longer includes 'U' for signatures made >> with a key that is either TRUST_UNDEFINED or TRUST_NEVER. > > Hmm, I can sort-of-see why you want to introduce a new placeholder > "%GT" to disambiguate two sources of 'U', but why would this change > to "%G?" necessary? U is re-introduced in v1. %GT is still there (since %G? doesn't print all trust levels) but I don't mind removing it (I added it for completeness sake when breaking backward-compatibility in v0).
Previously, signature verification for merge and pull operations checked if the key had a trust-level of either TRUST_NEVER or TRUST_UNDEFINED in verify_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-commit or verify-tag). The way it worked was by gpg-interface.c storing the result from the key/signature status *and* the lowest-two trust levels in the `result` member of the signature_check structure (the last of these status lines that were encountered got written to `result`). These are documented in GPG under the subsection `General status codes` and `Key related`, respectively [1]. The GPG documentation says the following on the TRUST_ status codes [1]: """ 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 conceptionally 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 in GOODSIG) and 'U' (as in TRUST_NEVER or TRUST_UNDEFINED) were both considered a success. The two cases where a result of 'U' had special meaning were in verify_merge_signature() (where this caused git to die()) and in format_commit_one() (where it affected the output of the %G? format specifier). I think it makes sense to refactor the processing of TRUST_ status lines such that users can configure a minimum trust level that is enforced globally, rather than have individual parts of git (e.g. merge) do it themselves. 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_ status code 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 the signature_check structure. This patch introduces a new configuration option: gpg.minTrustLevel. It consolidates trust-level verification to gpg-interface.c and adds a new `trust_level` member to the signature_check structure. Unfortunately, it breaks backward-compatibility in two ways: 1. The default trust level is TRUST_UNDEFINED. This is compatible with the old behavior of every code path *except* for verify_merge_signature() (since, again, it used to die()s on trust levels below TRUST_MARGINAL). 2. The %G? format specifier no longer includes 'U' for signatures made with a key that is either TRUST_UNDEFINED or TRUST_NEVER. Instead, a new %GT format specifier is introduced that outputs the trust level (as a complete string to avoid ambiguity with TRUST_UNDEFINED and TRUST_ULTIMATE). 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 (and it would also have broken backward-compatibility #1). 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 [2]. [1] https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=doc/doc/DETAILS;h=bd00006e933ac56719b1edd2478ecd79273eae72;hb=refs/heads/master [2] https://github.com/QubesOS/qubes-builder/blob/9674c1991deef45b1a1b1c71fddfab14ba50dccf/scripts/verify-git-tag#L43 Hans Jerry Illikainen (1): gpg-interface: add minTrustLevel as a configuration option Documentation/config/gpg.txt | 11 ++++ Documentation/pretty-formats.txt | 2 +- commit.c | 9 ++-- gpg-interface.c | 85 +++++++++++++++++++++++++----- gpg-interface.h | 10 +++- pretty.c | 20 ++++++- t/t5573-pull-verify-signatures.sh | 7 +++ t/t7510-signed-commit.sh | 19 ++++++- t/t7612-merge-verify-signatures.sh | 15 ++++++ 9 files changed, 157 insertions(+), 21 deletions(-)