Jeff King venit, vidit, dixit 27.01.2016 09:09:
> On Wed, Jan 27, 2016 at 08:53:08AM +0100, Michael J Gruber wrote:
>
>>> Yeah, definitely. My thinking was that `verify-tag` could learn a series
>>> of optional consistency checks, enabled by command line options, and
>>> verifying programs (or humans) could turn them on to avoid having to
>>> replicate them manually. So something like:
>>>
>>> git verify-tag \
>>> --verify-tagger-matches-key \
>>> --verify-tag-matches-ref \ # or --verify-tag-matches=v2.0.0
>>> v2.0.0
>>>
>>> or to implement more specific policy, maybe an option to check for a
>>> _specific_ tagger, either by email (as provided by gpg) or even key-id.
>>>
>>> Those are all things that are not _too_ hard to do if you're willing to
>>> parse gpg or git output, but we could make life easier for our callers.
>>> And hopefully by asking for specific, concrete checks, it doesn't
>>> introduce a false sense of security. I.e., we're not making a foolproof
>>> tool; we're making building blocks that one could use for a more
>>> foolproof tool.
>>
>> OK, let's make a tool that helps fooling as well as proofing :)
>>
>> I'll look into the tag header check. Maybe "--check-tagname"? "check"
>> seems to imply less than "verify".
>
> Yeah, I think that is fine (I actually wrote --check originally; I'm not
> quite sure why I decided to change it).
>
>> As for the gpg related stuff: We provide the full diagnostic output from
>> gpg on request. But I think a mismatch between the signing key's uid and
>> the taggers' name/email is more common than not,
>
> Is it? I'd think if you are using that name with a signed tag, you would
> bother to issue (and get people to sign) the matching uid. Certainly it
> is the case for git and linux signatures, but I admit that it a pretty
> small sampling size.
>
> The bigger issue is that gpg seems to give us only _one_ uid, when there
> may be several. E.g., Junio's v2.7.0 is signed by 96AFE6CB, which is a
> sub-key that has several uids associated with it. The one that "git
> verify-tag --raw" shows from gpg is gitster@xxxxxxxxx, which is good,
> but I think that's just because it happens to be the first uid. Or maybe
> there is some gpg arcana going on that I don't know about.
You do not sign with a uid, you sign with a (sub)key, and the tag is
signed with Junio's primary key. His subkey is encryption only.
uids do not identify keys, you can add and delete them at will without
changing the primary key id. To help recognize ("identify") a key, gpg
displays the uid with the most recent self-signature, which is usually
the most "recent uid".
You do sign a uid.
So, if you want to be sure that a tag is signed "with a specific uid" by
relying on signatures from a set of signers, you would really need to
check that the key that signed the tag has a signature on the correct
uid. Having a signed key with the right uid in it doesn't mean much
unlss the right uid is signed.
E.g., I have a key with many signatures, and I could have Junio's uid on
it in a minute without invalidating any of those signatures.
>> and on the other hand a
>> signature by a key identified by its uid is meaningless unless you keep
>> your keyring tidy... We could punt on that and let users identify the
>> key by any means that gpg allows, of course, and check that the
>> signature comes from whatever "gpg --list-key <userspecified>" gives as
>> long as it's unique.
>
> Right, I think it's an open question whether people actually participate
> in the web of trust. I don't have a good signature path to Junio's key,
> but I happen to know what it is based on past interaction.
>
> But then, I also do not really verify tags. Why would I? I routinely
> fetch and run "make" on the result, and there is no cryptographic
> protection there at all. Verifying tag signatures after a release seems
> all but pointless. :)
No signature protects us from our own dogfood :)
> I think for any of this to be useful, it has to be part of some tool
> that is very opinionated on policy. E.g., imagine a post-fetch hook that
> validated that each incoming commit was signed, and that the signer was
> part of a whitelisted group of keys that you "somehow" got hold of
> out-of-band for your project. That is not that useful for an open-source
> project, but I could see the appeal for a proprietary development
> environment.
That one is easy already by setting "GNUPGHOME" to a special dir with a
small keyring and tight trust settings (or having a dedicated account on
the incoming side in the first place).
Michael
--
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