Re: [RFC] tag-ref and tag object binding

> On Wed, Jan 27, 2016 at 08:23:02AM +0100, Michael J Gruber wrote:
> 
>>> Tag objects already have a "tag" header, which is part of the signed
>>> content. If you use "git verify-tag -v", you can check both that the
>>> signature is valid and that the tag is the one you are expecting.
>>
>> Yes, that's what I described in my last paragraph, using the term
>> (embedded) tag "name" which is technically wrong (it's not the tag
>> object's name, which would be a sha1) but the natural term for users.
> 
> Indeed. I should have read further back in the quoting. :)
> 
>>> Git pretty much punts on all of these issues and assumes either a human
>>> or a smarter tool is looking at the verification output. But I don't
>>> think it would hurt to build in some features to let git automatically
>>> check some things, if only to avoid callers duplicating work to
>>> implement the checks themselves.
>>
>> That is really a can of worms for several reasons:
>> [...]
>> So, for those who shy away from for-each-ref and such, we may add the
>> header check to verify-tag, with a big warning about the marginal gain
>> in security (or the requirements for an actual gain).
> 
> 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.