Jeff King venit, vidit, dixit 13.06.2014 10:02:
> On Fri, Jun 06, 2014 at 04:15:28PM +0200, Michael J Gruber wrote:
>> Commit signatures can be verified using "git show -s --show-signature"
>> or the "%G?" pretty format and parsing the output, which is well suited
>> for user inspection, but not for scripting.
>> Provide a command "verify-commit" which is analogous to "verify-tag": It
>> returns 0 for good signatures and non-zero otherwise, has the gpg output
>> on stderr and (optionally) the commit object on stdout, sans the
>> signature, just like "verify-tag" does.
>> Signed-off-by: Michael J Gruber <g...@drmicha.warpmail.net>
> I think the general direction of this series is reasonable.
> Did you give any thought to just having a "git verify" command, instead
> of separate tag/verify commands?
Yes. (mathematician's answer)
You know not only the outcome but also why I refrained from doing so:
compatibility. We would need to deprecate verify-tag.
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.
> Another thought, that may be orthogonal to your series: what does it
> mean to verify a commit? We check for _some_ signature from a key that
> is in your keyring. But we do not check whether the signature matches
> the committer field (or for tags, the tagger field). You have to parse
> the gpg output, run "git cat-file", and then correlate the two. Should
> there be an option to have git check that one of the signed uids from
> gpg matches the commit's committer?
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 <p...@peff.net> signed by some other
keys. 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html