Jonathan Nieder <jrnieder@xxxxxxxxx> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html