From: Junio C Hamano <gitster@pobox.com>
To: KellerFuchs <KellerFuchs@hashbang.sh>
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 09:41:22 -0700 [thread overview]
Message-ID: <xmqqtwj8rtcd.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20160411003242.GC9034@hashbang.sh> (KellerFuchs@hashbang.sh's message of "Mon, 11 Apr 2016 00:32:42 +0000")
KellerFuchs <KellerFuchs@hashbang.sh> writes:
> 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].
OK, so it is wrong to talk about "trusted" and/or "valid" "GPG
signatures" like the original one. We should say "... have GPG
signatures that were signed by valid key" (not "trusted" key)?
> 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.
Thanks for clarification. The distinction between trusted and valid
should at least be in the log message and possibly (if we can find a
good way to flow it into the description) added to the documentation.
Perhaps like this?
Verify that the tip commit of the side branch being merged is
signed with a valid key (i.e. a key that is signed by a key that
the user set the trust level as trusted), and abort the merge if
it is not.
next prev parent reply other threads:[~2016-04-11 16:41 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
2016-04-11 16:41 ` Junio C Hamano [this message]
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=xmqqtwj8rtcd.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=KellerFuchs@hashbang.sh \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--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.