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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Oct 6, 2011, 17:11 UTC
Message-ID: <20111006171107.GA10973@elie>
In-Reply-To: <CAJo=hJvWbjEM9E5AjPHgmQ=eY8xf=Q=xtukeu2Ur7auUqeabDg@mail.gmail.com>

Shawn Pearce wrote:

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

Show 6 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)

[...]

> I like this approach better than the prior "push certificate" idea.
> The signature information is part of the history graph

I probably missed some earlier discussion (so please forgive me this), but how is it intended to be used? Would projects

 a. require as a matter of policy that all commits be signed
 b. just sign releases as usual, but as commits in the history graph
    instead of tags
 c. sign the occasional especially interesting commit

What happens if my old key is compromised and I want to throw away the signatures and replace them with signatures using my new key? How does this relate to the "push certificate" use case, which seemed to be mostly about authenticating published branch tips with signatures that are not necessarily important in the long term?

In other words, something like this feature sounds like a sensible way to commit the equivalent of a GPG-signed patch, but it doesn't seem like a good fit for the "push certificate" use cases.