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

> Jeff King venit, vidit, dixit 27.01.2016 08:33:
> > 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.
> 
> 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".

> 
> 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, 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.
> 
> But maybe I'm biased by my zoo of uids/emails addresses/full name
> spellings... and general paranoia regarding the term "verify" ;)