Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)
- Date: Tue, 7 Mar 2017 04:23:54 -0500
- From: Jeff King <peff@xxxxxxxx>
- Subject: Re: [Request for Documentation] Differentiate signed (commits/tags/pushes)
On Mon, Mar 06, 2017 at 11:59:24AM -0800, Stefan Beller wrote:
> What is the difference between signed commits and tags?
> (Not from a technical perspective, but for the end user)
I think git has never really tried to assign any _meaning_ to the
signatures. It implements the technical bits and leaves it up to the
user and their workflows to decide what a given signature means.
People generally seem to take tag signatures to mean one (or both) of:
1. Certifying that the tree contents at that tag are the official,
signed release contents (i.e., this is version 1.0, and I'm the
maintainer, so believe me).
2. Certifying that all the history leading up to that tag is
"official" in some sense (i.e., I'm the maintainer, and this was
the tip of my git tree at the time I tagged the release).
Signing individual commits _could_ convey meaning (2), but "all history
leading up" part is unlikely to be something that the signer needs to
enforce on every commit.
In my opinion, the most useful meaning for commit-signing is simply to
cryptographically certify the identity of the committer. We don't
compare the GPG key ident to the "committer" field, but IMHO that would
be a reasonable optional feature for verify-commit (I say optional
because we're starting to assign semantics now).
I think one of the reasons kernel (and git) developers aren't that
interested in signed commits is that they're not really that interesting
in a patch workflow. You're verifying the committer, who in this project
is invariably Junio, and we just take his word that whatever is in the
"author" field is reasonable.
But for a project whose workflow is based around pushing and pulling
commits, I think it does make sense. The author field may not always
match the committer (e.g., in a cherry-pick), but it still lets you
trace that attestation of the author back to the committer. And it's up
to UI to make that distinction clear (e.g., if you push a signed
cherry-pick to GitHub, the commit is labeled with something like "A U
Thor committed with C O Mitter", and then you get a little "Verified"
tag for C O Mitter that gives you more information about the signature).
So I don't think it's just a checkbox feature. It's a useful thing for
certain workflows that really want to be able to attribute individual
commits with cryptographic strength.