From: John Keeping <john@keeping.me.uk>
To: Thomas Rast <trast@inf.ethz.ch>
Cc: "Sebastian Götte" <jaseg@physik.tu-berlin.de>,
git@vger.kernel.org, gitster@pobox.com
Subject: Re: [PATCH v7 4/5] merge/pull Check for untrusted good GPG signatures
Date: Sun, 31 Mar 2013 16:26:37 +0100 [thread overview]
Message-ID: <20130331152637.GH2286@serenity.lan> (raw)
In-Reply-To: <87mwtjwqzz.fsf@linux-k42r.v.cablecom.net>
On Sun, Mar 31, 2013 at 05:03:44PM +0200, Thomas Rast wrote:
> John Keeping <john@keeping.me.uk> writes:
>
> > On Sun, Mar 31, 2013 at 04:33:57PM +0200, Sebastian Götte wrote:
> >> diff --git a/commit.c b/commit.c
> >> index eda7f90..bb2d9ad 100644
> >> --- a/commit.c
> >> +++ b/commit.c
> >> @@ -1029,6 +1029,8 @@ static struct {
> >> } sigcheck_gpg_status[] = {
> >> { 'G', "[GNUPG:] GOODSIG " },
> >> { 'B', "[GNUPG:] BADSIG " },
> >> + { 'U', "[GNUPG:] TRUST_NEVER" },
> >> + { 'U', "[GNUPG:] TRUST_UNDEFINED" },
> >> };
> >>
> >> static void parse_gpg_output(struct signature_check *sigc)
> >> @@ -1050,11 +1052,12 @@ static void parse_gpg_output(struct signature_check *sigc)
> >> found += strlen(sigcheck_gpg_status[i].check);
> >> }
> >> sigc->result = sigcheck_gpg_status[i].result;
> >> - sigc->key = xmemdupz(found, 16);
> >> - found += 17;
> >> - next = strchrnul(found, '\n');
> >> - sigc->signer = xmemdupz(found, next - found);
> >> - break;
> >> + if (sigc->result != 'U') {
> >
> > This could use a comment; we know now that only GOODSIG and BADSIG
> > are followed by a signature, but someone looking at this code in the
> > future will probably appreciate an explanation.
>
> Wouldn't it be even less magical if there was an explicit field in the
> struct that says whether we need to read a sig from such a line?
Yeah, that would be even better.
> And furthermore, to use an enum instead of a char so that you can easily
> spell out the details in the code? This also has the advantage that the
> compiler can check that your 'switch'es cover all cases.
>
> That's of course assuming that I interpret the logic right; my current
> understanding is that:
>
> * U means untrusted, which is bettern than B but worse than G;
Yes, although I wonder if we should split TRUST_NEVER and
TRUST_UNDEFINED (and maybe handle TRUST_MARGINAL as well) and print
different messages in each case.
> * GPG guarantees that the last line matching any of the patterns is the
> one we care about, so we can blindly override one with the other
The DETAILS file in GPG says:
For each signature only one of the codes GOODSIG, BADSIG, EXPSIG,
EXPKEYSIG, REVKEYSIG or ERRSIG will be emitted.
so we should be OK here.
next prev parent reply other threads:[~2013-03-31 15:27 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-23 1:57 [PATCH v2 1/4] Move commit GPG signature verification to commit.c Sebastian Götte
2013-03-25 15:54 ` Junio C Hamano
2013-03-25 23:46 ` [PATCH 0/5] Verify GPG signatures when merging and extend %G? pretty string Sebastian Götte
2013-03-26 1:46 ` Junio C Hamano
2013-03-26 11:05 ` [PATCH v4 " Sebastian Götte
2013-03-26 16:26 ` Junio C Hamano
2013-03-26 16:43 ` Sebastian Götte
[not found] ` <cover.1364295502.git.jaseg@physik-pool.tu-berlin.de>
2013-03-26 11:05 ` [PATCH v4 1/5] Move commit GPG signature verification to commit.c Sebastian Götte
2013-03-26 11:05 ` [PATCH v4 2/5] commit.c/GPG signature verification: Also look at the first GPG status line Sebastian Götte
2013-03-28 22:33 ` Junio C Hamano
2013-03-26 11:05 ` [PATCH v4 3/5] merge/pull: verify GPG signatures of commits being merged Sebastian Götte
2013-03-28 22:33 ` Junio C Hamano
2013-03-30 0:13 ` [PATCH v5 0/5] Verify GPG signatures when merging and extend %G? pretty string Sebastian Götte
[not found] ` <cover.1364601337.git.jaseg@physik-pool.tu-berlin.de>
2013-03-30 0:14 ` [PATCH v5 1/5] Move commit GPG signature verification to commit.c Sebastian Götte
2013-03-30 3:37 ` Junio C Hamano
2013-03-30 0:14 ` [PATCH v5 2/5] commit.c/GPG signature verification: Also look at the first GPG status line Sebastian Götte
2013-03-30 3:37 ` Junio C Hamano
2013-03-30 0:14 ` [PATCH v5 3/5] merge/pull: verify GPG signatures of commits being merged Sebastian Götte
2013-03-30 3:38 ` Junio C Hamano
2013-03-30 14:14 ` [PATCH v6 0/5] Verify GPG signatures when merging and extend %G? pretty string Sebastian Götte
[not found] ` <cover.1364652339.git.jaseg@physik-pool.tu-berlin.de>
2013-03-30 14:15 ` [PATCH v6 1/5] Move commit GPG signature verification to commit.c Sebastian Götte
2013-03-30 14:15 ` [PATCH v6 2/5] commit.c/GPG signature verification: Also look at the first GPG status line Sebastian Götte
2013-03-30 14:15 ` [PATCH v6 3/5] merge/pull: verify GPG signatures of commits being merged Sebastian Götte
2013-03-30 14:16 ` [PATCH v6 4/5] merge/pull Check for untrusted good GPG signatures Sebastian Götte
2013-03-30 14:16 ` [PATCH v6 5/5] pretty printing: extend %G? to include 'N' and 'U' Sebastian Götte
2013-03-30 0:14 ` [PATCH v5 4/5] merge/pull Check for untrusted good GPG signatures Sebastian Götte
2013-03-31 8:32 ` Thomas Rast
2013-03-31 10:55 ` Sebastian Götte
2013-03-31 11:38 ` Thomas Rast
2013-03-31 11:57 ` Sebastian Götte
2013-03-31 12:16 ` Thomas Rast
2013-03-31 12:27 ` Sebastian Götte
2013-03-31 13:33 ` John Keeping
2013-03-31 14:32 ` [PATCH v7 0/5] Verify GPG signatures when merging and extend %G? pretty string Sebastian Götte
[not found] ` <cover.1364738348.git.jaseg@physik-pool.tu-berlin.de>
2013-03-31 14:32 ` [PATCH v7 1/5] Move commit GPG signature verification to commit.c Sebastian Götte
2013-03-31 14:32 ` [PATCH v7 2/5] commit.c/GPG signature verification: Also look at the first GPG status line Sebastian Götte
2013-03-31 14:41 ` John Keeping
2013-03-31 14:33 ` [PATCH v7 3/5] merge/pull: verify GPG signatures of commits being merged Sebastian Götte
2013-03-31 14:33 ` [PATCH v7 4/5] merge/pull Check for untrusted good GPG signatures Sebastian Götte
2013-03-31 14:44 ` John Keeping
2013-03-31 15:03 ` Thomas Rast
2013-03-31 15:21 ` Sebastian Götte
2013-03-31 15:27 ` Thomas Rast
2013-03-31 15:26 ` John Keeping [this message]
2013-03-31 15:58 ` [PATCH v8 0/5] Verify GPG signatures when merging and extend %G? pretty string Sebastian Götte
[not found] ` <cover.1364742659.git.jaseg@physik-pool.tu-berlin.de>
2013-03-31 16:00 ` [PATCH v8 1/5] Move commit GPG signature verification to commit.c Sebastian Götte
2013-03-31 16:01 ` [PATCH v8 2/5] commit.c/GPG signature verification: Also look at the first GPG status line Sebastian Götte
2013-03-31 16:02 ` [PATCH v8 3/5] merge/pull: verify GPG signatures of commits being merged Sebastian Götte
2013-04-01 2:47 ` Junio C Hamano
2013-04-01 12:53 ` Sebastian Götte
2013-04-01 14:55 ` Junio C Hamano
2013-03-31 16:02 ` [PATCH v8 4/5] merge/pull Check for untrusted good GPG signatures Sebastian Götte
2013-03-31 16:03 ` [PATCH v8 5/5] pretty printing: extend %G? to include 'N' and 'U' Sebastian Götte
2013-03-31 14:34 ` [PATCH v7 " Sebastian Götte
2013-03-30 0:15 ` [PATCH v5 " Sebastian Götte
2013-03-26 11:05 ` [PATCH v4 4/5] merge/pull Check for untrusted good GPG signatures Sebastian Götte
2013-03-26 11:05 ` [PATCH v4 5/5] pretty printing: extend %G? to include 'N' and 'U' Sebastian Götte
[not found] ` <cover.1364254748.git.jaseg@physik-pool.tu-berlin.de>
2013-03-25 23:46 ` [PATCH 1/5] Move commit GPG signature verification to commit.c Sebastian Götte
2013-03-25 23:46 ` [PATCH 2/5] commit.c/GPG signature verification: Also look at the first GPG status line Sebastian Götte
2013-03-25 23:46 ` [PATCH 3/5] merge/pull: verify GPG signatures of commits being merged Sebastian Götte
2013-03-25 23:46 ` [PATCH 4/5] merge/pull Check for untrusted good GPG signatures Sebastian Götte
2013-03-25 23:46 ` [PATCH 5/5] pretty printing: extend %G? to include 'N' and 'U' Sebastian Götte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130331152637.GH2286@serenity.lan \
--to=john@keeping.me.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jaseg@physik.tu-berlin.de \
--cc=trast@inf.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).