Subkeys renewing/expiring strategy
kloecker at kde.org
Thu Oct 13 19:05:33 CEST 2022
On Donnerstag, 13. Oktober 2022 11:39:41 CEST nect via Gnupg-users wrote:
> > Since I use this key exclusively for commit signing, I can
> > simply replace it with a completely different key if I change my mind.
> About this, how do you deal-or plan of dealing- with past commits signed
> with a now expired key?
> I created on year ago a test repo with only one commit, signed with my now
> expired subkey.
> Checking that commit's signature now shows an alert saying that the key is
> expired (in red).
> While this is correct, I guess that some users or services may see expired
> signatures as invalid, even though they are valid and I just superseded
> them with newer subkeys.
> I can think of two choices: either resign all your past commits every time
> your subkey expires,
I don't think that's an option (at least not for a repo shared with others)
because it would rewrite the history of the git repo.
> or ignore the fact that old commits were signed with
> expired subkeys.
> So, I was wondering if extending the expiry is the better way to deal with
> this, since you avoid showing any alert for old commits.
The best option is probably to follow Teemu's advice and use a signing subkey
with unlimited validity.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users