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

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Oct 6, 2011, 17:22 UTC
Message-ID: <vpqfwj6xceo.fsf@bauges.imag.fr>
In-Reply-To: <20111006171107.GA10973@elie>

Jonathan Nieder <jrnieder@gmail.com> writes:

> I probably missed some earlier discussion (so please forgive me this),

(same here)

> 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?

With the patch we're discussing, signatures are part of history, hence can't be modified after the fact without rewritting them.

*But*, by design, unless sha1 itself is compromized (in which case Git would need to change to another hash function, that would be no fun), signing the tip of every branch is sufficient to sign the whole history.

So, your old signatures would remain there, and your new signature, for new commits, would be added on top.

> 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?

I'm wondering how this feature would fit in a typical flow, indeed. Usually, I hack for a while, and when I'm happy enough, I push. But I don't take the decision of what to push at commit time, so if the idea is to sign only a few commits (i.e. the ones you push), then you should decide this at commit time ("hmm, I should commit --gpg-sign this time because I'm going to push this one").

If the idea is to sign every commit, then there should be a config option so that we don't have to type it every time.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/