Treat expiry as a scheduled task. Either extend the key's expiry date or create a new key, then publish the updated public key and fingerprint in several places and announce it before the date. Do not wait for users to see verification errors.
Expiry is a feature
GnuPG lets you set an expiration date when you create a key. Its manual describes the expire argument accepting dates or periods such as days, weeks, months or years, and also allows a value meaning no expiry. Choosing a date means a lost or forgotten key eventually stops being valid on its own.
That is useful. It does mean someone has to own the renewal.
Decide: extend or replace
| Situation | Better choice |
|---|---|
| Key is safe, date approaching | Extend the expiry and republish the public key |
| Key may have been exposed | Revoke and replace, do not extend |
| Maintainer who held the key left | Replace, and retire the old key |
| Algorithm or size is now below your policy | Replace |
Extending changes the public key, so users must fetch the updated copy. Replacing means users must learn a new fingerprint. Both need communication.
Steps
- Put the date in a calendar for everyone who can sign releases, well ahead of expiry.
- Decide extend or replace using the table above.
- Publish the result in more than one place. The project website, the repository, release notes and your documentation page for verifying releases. If an attacker changes only one location, a mismatch will be visible.
- Announce the change in the release notes and any mailing list or news feed you run, with the new fingerprint.
- Keep old releases verifiable. Users still need to check files signed under the old key. Say plainly which versions each key covers.
- Update CI and tooling that holds the key or fingerprint.
What users see
When verification runs after expiry, tools usually report the key as expired. Behaviour can depend on the tool and on whether signature time or current time is used, so state in your docs what users should expect. Our post on writing a verify page for your releases shows what to include.
Prepare for the bad day too
Expiry is the gentle case. If a key is stolen, you need a revocation certificate ready. See what a GPG revocation certificate is and when to create it.
A worked timeline
Suppose the key expires on a known date. Ninety days before, a calendar reminder fires and the owner decides extend or replace. Sixty days before, the updated public key or new fingerprint is published in the repository and on the website. Thirty days before, the release notes of the next release mention the change. On the day, nothing breaks, because users already hold the new key. After the date, the verify page lists both keys with the releases each one covered. The point of the timeline is that no step depends on a user noticing an error message first.
Keep a second person able to do the renewal, so the plan does not rest on one laptop or one memory.
Quick check
Should release keys never expire?
Reasonable teams differ. An expiry date forces a periodic review of who holds the key, which many find worthwhile, provided someone owns the renewal.
Do old signatures become invalid when the key expires?
Tool behaviour varies. Document how your users should verify older releases so they are not left guessing.
Sources
Last reviewed: 19 October 2026.
