Re: [git patches] libata updates, GPG signed (but see admin notes)

From: Jeff King <peff@peff.net>
Date: Nov 3, 2011, 02:55 UTC
Message-ID: <20111103025532.GB9492@sigill.intra.peff.net>
In-Reply-To: <CAJo=hJv5nAKH_ptYSWfMvFQv0Dj+naPXK35wSzKYkfPOYsWkxg@mail.gmail.com>

On Wed, Nov 02, 2011 at 06:02:37PM -0700, Shawn O. Pearce wrote:

Show 12 quoted lines

> > So I really think that signing the top commit itself is fundamentally wrong.
> 
> I really disagree. I like the signed commit approach. It allows for a
> lot more workflows than just providing a way for you to validate a
> pull from a trusted lieutenant. Debian/Gentoo folks want a way to sign
> every commit in their workflow. Just because you don't want that and
> think its crazy doesn't mean its not a valid workflow for that
> community and is something Git shouldn't support. I never use `git
> stash`. I hate the damn command. Yet its still there. I just choose
> not to use it. Junio's gpgsig header on each commit is also optional,
> and communities/contributors can choose to use (or ignore) the feature
> as they need to.

Stop for a minute and think about what it _means_ to sign a commit. Is it saying "I wrote this commit?" Or "I think this commit is good?" Or "I think all of the history leading to this is good?" It's obviously going to be a per-project thing, but it's very constricting. Leaving aside all of the workflow issues Linus brought up (but which I do agree with), think about what it would mean for Linus to fetch a commit from a lieutenant and then sign it. Whatever it means, it can really only be _one_ thing.

But big projects that are interested in signatures probably want to say more. They want to say "this developer really wrote this commit". They want to say "QA passed this commit". They want to say "the history up to here looks good". And so on.

But they can't say those things without binding some data to the commit (i.e., making a certificate saying "this commit passed QA"). Data which might only make sense to assert much later than the commit is written.

So you're going to need to support detached commit signatures in some form anyway to make everybody happy. Which isn't to say in-commit signatures are wrong, but they are just one tool in a toolbox.

Personally, I think the only thing that makes sense to assert inside a commit itself is that you are the author, and the author line of the key should match the email UID of the signing key. And then anything you want to say about _other_ people's commits (or even your own commits, but later) should come in the form of detached signatures with some content.

That's how signed tags work. It's not just Linus signing a commit. It's Linus signing a binding between a commit and the statement "this is v2.6.28". The only thing wrong with the signed tag model for more general use is that you need some way of naming and organizing large numbers of tags (e.g., several per commit if you have things like QA signatures).

-Peff