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

From: Jeff King <peff@peff.net>
Date: Jan 27, 2016, 07:33 UTC
Message-ID: <20160127073357.GA7066@sigill.intra.peff.net>
In-Reply-To: <56A87056.2010309@drmicha.warpmail.net>

On Wed, Jan 27, 2016 at 08:23:02AM +0100, Michael J Gruber wrote:

Show 7 quoted lines

> > 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. :)

Show 11 quoted lines

> > 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.

-Peff