git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [PATCH 0/1] gpg-interface: add minTrustLevel as a configuration option
@ 2019-12-16 15:32 Hans Jerry Illikainen
  2019-12-16 15:32 ` [PATCH 1/1] " Hans Jerry Illikainen
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Hans Jerry Illikainen @ 2019-12-16 15:32 UTC (permalink / raw)
  To: git; +Cc: Hans Jerry Illikainen

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(-)

-- 
2.24.1.485.gad05a3d8e5.dirty


^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2019-12-27 22:21 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-16 15:32 [PATCH 0/1] gpg-interface: add minTrustLevel as a configuration option Hans Jerry Illikainen
2019-12-16 15:32 ` [PATCH 1/1] " Hans Jerry Illikainen
2019-12-20 22:57   ` SZEDER Gábor
2019-12-21 18:59     ` Hans Jerry Illikainen
2019-12-23 14:50       ` Randall S. Becker
2019-12-24 11:30         ` Hans Jerry Illikainen
2019-12-24 14:20           ` Randall S. Becker
2019-12-16 20:58 ` [PATCH 0/1] " Junio C Hamano
2019-12-18 23:59   ` Hans Jerry Illikainen
2019-12-19  0:01 ` [PATCH v1 " Hans Jerry Illikainen
2019-12-19  0:01   ` [PATCH v1 1/1] " Hans Jerry Illikainen
2019-12-22  0:31   ` [PATCH v2 0/1] " Hans Jerry Illikainen
2019-12-22  0:31     ` [PATCH v2 1/1] " Hans Jerry Illikainen
2019-12-24 19:02       ` Junio C Hamano
2019-12-27 13:46         ` Hans Jerry Illikainen
2019-12-27 22:21           ` Junio C Hamano
2019-12-22  0:44     ` [PATCH v2 0/1] " Hans Jerry Illikainen
2019-12-27 13:55     ` [PATCH v3 " Hans Jerry Illikainen
2019-12-27 13:55       ` [PATCH v3 1/1] " Hans Jerry Illikainen

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).