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: Tue, 12 Apr 2016 01:00:09 +0000 [thread overview]
Message-ID: <20160412010009.GD9034@hashbang.sh> (raw)
In-Reply-To: <xmqqtwj8rtcd.fsf@gitster.mtv.corp.google.com>
On Mon, Apr 11, 2016 at 09:41:22AM -0700, Junio C Hamano wrote:
> KellerFuchs <KellerFuchs@hashbang.sh> writes:
> > 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)?
Well, the GnuPG documentation also talks of valid signatures,
and it is a convenient short-hand:
https://www.gnupg.org/documentation/manuals/gpgme/Verify.html
On the other hand, being more explicit here cannot hurt.
> 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.
Ok. I will have a second go at the patch (with the split you requested,
a more explicit description and an explanation in the commit msg).
What is the prefered way to send a second version of a patchset here?
Just git-email-ing it here In-Reply-To the first mail?
> 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.
I would rather see something like
> Verify that the tip commit of the side branch being merged is
> signed with a valid key, i.e. a key that has a valid uid: in the
> default trust model, this means it has been signed by a trusted key.
> If the tip commit of the side branch is not signed with a valid key,
> the merge is aborted.
It's unfortunately more verbose, but I don't want to make promises
about GnuPG's behaviour that depends on the user's configuration.
Best,
kf
next prev parent reply other threads:[~2016-04-12 1:00 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
2016-04-12 1:00 ` KellerFuchs [this message]
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=20160412010009.GD9034@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.