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

From: Jeff King <peff@peff.net>
Date: Jan 27, 2016, 08:09 UTC
Message-ID: <20160127080901.GA7651@sigill.intra.peff.net>
In-Reply-To: <56A87764.9070101@drmicha.warpmail.net>

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

Show 24 quoted lines

> > 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@pobox.com, 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.

Show 6 quoted lines

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

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.

-Peff