4 ms·
Sorry I did mean valid while the key is valid, of course. The scenario I'm describing is simpler: - You create a PGP key - You sign a commit with that key -
by rakoo 6y ago
Sorry I did mean valid while the key is valid, of course.
The scenario I'm describing is simpler:
- You create a PGP key
- You sign a commit with that key
- The key expires (you definitely should have a key rotation process in-place, so keys should expire)
- I want to use your commit. I see it is signed but the key is expired. What is the value of the signature at this moment ?
When a key is expired your commits don't automatically become bad, they just become "unverifiable" but you can't resign them without changing their hash; that's why signing tags is better because you can re-sign tags quickly (before the key is expired).
> Would your concern be addressed by having transparency logs for both the certs and keys?
Transparency logs only catch the problem after they appear and raise the chance that they are detected but they don't prevent it from happening. If we're talking about making sure no one changes your patches/commits under your feets, a transparency log of commits is "enough", and that's basically what the git repository is all about.