Re: [PATCH] commit: teach --gpg-sign option

From: Shawn Pearce <spearce@spearce.org>
Date: Oct 6, 2011, 15:50 UTC
Message-ID: <CAJo=hJvWbjEM9E5AjPHgmQ=eY8xf=Q=xtukeu2Ur7auUqeabDg@mail.gmail.com>
In-Reply-To: <7vaa9f3pk8.fsf@alter.siamese.dyndns.org>

On Wed, Oct 5, 2011 at 17:56, Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

> And this uses the gpg-interface.[ch] to allow signing the commit, i.e.
>
>    $ git commit --gpg-sign -m foo
>    You need a passphrase to unlock the secret key for
>    user: "Junio C Hamano <gitster@pobox.com>"
>    4096-bit RSA key, ID 96AFE6CB, created 2011-10-03 (main key ID 713660A7)
>
>    [master 8457d13] foo
>     1 files changed, 1 insertions(+), 0 deletions(-)
>
> The lines of GPG detached signature are placed in new header lines, after
> the standard tree/parent/author/committer headers, instead of tucking the
> signature block at the end of the commit log message text (similar to how
> signed tag is done), for multiple reasons:

I like this approach better than the prior "push certificate" idea. The signature information is part of the history graph, and won't be stripped or forgotten to be published as commits flow through development trees, provided that the commit SHA-1 was preserved by not doing a rewrite. There is no merge race on the server side to get a branch updated.

The signature is automatically stripped by older Git tools like commit --amend, format-patch or rebase, where the signature would be made invalid anyway by changing the tree, parent or committer. That is a nice bit of backward compatibility there. Of course there is some concern this signature data will show up incorrectly on clients that are so ancient they don't understand the "encoding" header, but those clients are already very ancient, and already do not process encoding correctly.

-- 
Shawn.