From: KellerFuchs <KellerFuchs@hashbang.sh>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org,
"Michael J. Gruber" <git@drmicha.warpmail.net>,
"Brian M. Carlson" <sandals@crustytoothpaste.ath.cx>
Subject: Re: [PATCH] Documentation: clarify signature verification
Date: Mon, 11 Apr 2016 00:32:42 +0000 [thread overview]
Message-ID: <20160411003242.GC9034@hashbang.sh> (raw)
In-Reply-To: <xmqqa8l1ti8d.fsf@gitster.mtv.corp.google.com>
On Sun, Apr 10, 2016 at 11:46:10AM -0700, Junio C Hamano wrote:
> > --- a/Documentation/merge-options.txt
> > +++ b/Documentation/merge-options.txt
> > @@ -89,8 +89,10 @@ option can be used to override --squash.
> >
> > --verify-signatures::
> > --no-verify-signatures::
> > - Verify that the commits being merged have good and trusted GPG signatures
> > + Verify that the commits being merged have good and valid GPG signatures
> > and abort the merge in case they do not.
> > + For instance, when running `git merge --verify-signature remote/branch`,
> > + only the head commit on `remote/branch` needs to be signed.
>
> The first part of this change and all other changes are of dubious
> value, but the last two lines is truly an improvement--it adds
> missing information people who use the feature may care about.
The reason for the first edit is that “trusted” and “valid” are OpenPGP
concepts: a key is trusted if the user set a trust level for it,
and a uid is valid if it has been signed by a trusted key [0].
Most of my confusion came from this, since it sounded like the signature
would only be accepted if it came from a key with a non-zero ownertrust.
[0] That actually only holds for the default trust model,
so I'm oversimplifying a bit here.
> I'd suggest doing the addition of the last two lines as a standalone
> patch, and make the remainder a separate patch on top.
Sure, will do when submitting for inclusion.
> > diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> > index 671cebd..29b19b9 100644
> > --- a/Documentation/pretty-formats.txt
> > +++ b/Documentation/pretty-formats.txt
> > @@ -143,8 +143,8 @@ ifndef::git-rev-list[]
> > - '%N': commit notes
> > endif::git-rev-list[]
> > - '%GG': raw verification message from GPG for a signed commit
> > -- '%G?': show "G" for a Good signature, "B" for a Bad signature, "U" for a good,
> > - untrusted signature and "N" for no signature
> > +- '%G?': show "G" for a good (valid) signature, "B" for a bad signature,
> > + "U" for a good signature with unknown validity and "N" for no signature
>
> The reason I said the other changes are of dubious value is shown
> very well in this hunk. I am not sure if it is an improvement to
> rephrase "Good" to "good (valid)" and "untrusted" to "good signature
> with unknown validity". They are saying pretty much the same thing,
> no?
As said above, it was about consistency with the OpenPGP terminology.
If git wants to have it's own vocabulary for that (which I would argue
against), then it would need to be defined somewhere.
> > diff --git a/Documentation/pretty-options.txt b/Documentation/pretty-options.txt
> > index 54b88b6..62cbae2 100644
> > --- a/Documentation/pretty-options.txt
> > +++ b/Documentation/pretty-options.txt
> > @@ -78,5 +78,5 @@ being displayed. Examples: "--notes=foo" will show only notes from
> > endif::git-rev-list[]
> >
> > --show-signature::
> > - Check the validity of a signed commit object by passing the signature
> > - to `gpg --verify` and show the output.
> > + Check the validity of a signed commit object, by passing the signature
> > + to `gpg --verify`, and show the output.
>
> The update one may be gramattically correct, but I personally find
> the original easier to read. Is there a reason for this change?
That one is arguably more dubious, and I would happily drop it.
For some reason, I kept parsing it as “Check the validity [...] by
(passing the signature to `gpg --verify` and showing the output)”.
Best regards,
kf
next prev parent reply other threads:[~2016-04-11 0:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-09 20:08 [PATCH] Documentation: clarify signature verification The Fox in the Shell
2016-04-10 18:46 ` Junio C Hamano
2016-04-11 0:32 ` KellerFuchs [this message]
2016-04-11 16:41 ` Junio C Hamano
2016-04-12 1:00 ` KellerFuchs
2016-04-12 15:48 ` Junio C Hamano
2016-05-13 9:51 ` Fox in the shell
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=20160411003242.GC9034@hashbang.sh \
--to=kellerfuchs@hashbang.sh \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sandals@crustytoothpaste.ath.cx \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.