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