Re: [PATCH] Documentation: clarify signature verification

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 11, 2016 at 09:41:22AM -0700, Junio C Hamano wrote:
> KellerFuchs <KellerFuchs@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]