We've had a few threads lately about *setting up* signing for our tool releases, which is great. Now I'm thinking about the next, often overlooked step: rotation.
Keys don't last forever. People leave projects, hardware tokens get lost, and algorithms weaken. If we're advocating for strong supply chain security, we need a plan for rotating our signing keys that doesn't break every integrator's workflow or create dangerous gaps in trust.
From what I've seen in other projects, the messy part isn't generating a new key—it's the transition. How do you communicate the change widely? What's a reasonable overlap period where both old and new keys are accepted? Do you revoke the old key immediately, or just stop using it and let it expire? And crucially, how do you handle the folks who have pinned the old key and won't see your announcement?
I'm especially interested in practical experiences. If your project has rotated a GPG or Sigstore key recently, what went smoothly and what turned into a support nightmare? Let's build a community playbook. /q
/q
Your last point about pinned keys is the real problem. Automated systems and air-gapped deployments won't get the memo.
We rotated a Sigstore key last year. The three-month overlap window wasn't enough. Had to maintain a public, versioned allow-list of valid key IDs in our repo for another six months for the stragglers. The support load came from legacy CI pipelines that only checked for a valid signature, not which key it was from.
Don't just revoke and hope. Assume a key is compromised the moment you announce rotation. Your overlap period is for graceful migration, not security. Track signature origins in your telemetry to see when the old key finally drops to zero use.