On Fri, Jun 13, 2014 at 11:55:22AM +0200, Michael J Gruber wrote: > > Did you give any thought to just having a "git verify" command, instead > > of separate tag/verify commands? > > Yes. (mathematician's answer) Cute. > You know not only the outcome but also why I refrained from doing so: > compatibility. We would need to deprecate verify-tag. Yes, we'd certainly leave verify-tag in place for compatibility. I don't think that makes "git verify" a bad idea necessarily, if it is a better interface. But... > But there is also a more subtle reason: If you want to verify a signed > commit, you want to be sure that it actually is a commit. "verify" could > easily branch code paths based on the object type, but I'm not sure that > is desirable, at least not by default. Yes, I wasn't sure about that part. I think it really depends on what people want to use it for. I was thinking more of a porcelain, anyway, to just check whatever signatures are available. But I don't really sign my commits right now anyway, so I'm somewhat guessing. Even if we decide to do something like that, I suppose having verify-commit isn't the end of the world. It could just remain the plumbing interface, as verify-tag would. So I don't think my half-formed thoughts are any reason to block your series. > That is a general issue with verifying signatures: it can be automated > only if you employ a strict trust model and a very limited keyring. > "valid signature" means only as much as the signatures that your gpg > accepts can be really trusted. > > Comparing uid's really buys you nothing in the sense that everyone can > have a key with uid "Jeff King <peff@xxxxxxxx> signed by some other > keys. Sort of. The crypto proves that the commit was signed by a particular key, and then there are two mappings: 1. What is the identity associated with that key? 2. Is that identity somebody who "should" have signed the commit? We assume that GPG takes care of the first one with the web of trust. Even if you have the key and can check the signature, it will still complain about an untrusted uid (and we reflect that with 'U' in the gpg status). There is no point in looking at step 2 if step 1 did not check out. For the second one, I think it really depends on the project workflow, and you may even want multiple policies within a project (e.g., perhaps only some uids can merge to master). But one obvious check we can make is "does the identity in the commit data match one of the uids?". True, you don't _need_ that; you can always just use "%GS", and throw away the committer and author headers. But we show those names in lots of output. You could, for example, "verify" that each commit's author id matches its gpg signature, and then use the regular tools to do further work (e.g., running "git blame"), and be confident that the author you see matches the signature. This should definitely be optional. Even something as simple as "author id matches the gpg key" would not always work (for example, in git.git we pick patches from the list, which means only Junio can sign the objects, but he is not the author). But just because it is optional does not mean it would not be a useful tool for some workflows. > On the other hand, it's perfectly OK to use different uids for git > commits and signatures. The e-mail address I use for the git list and > commits, for example, is clearly a "plus address", which helps me > organize things; my personal key has the primary address as uid. > > I really think all this is up to local policies for individual use cases. Very much agreed. My suggestion was more about providing tools for people to build those policies. I realize this isn't really your itch to scratch. It's just that when I see a description like "verify a commit", I wonder what exactly "verify" means. -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