How we revoke an add-on signing key

Every Sekervia add-on is signed (Ed25519). The application rejects any add-on whose signature does not match a key it knows. But signing is not enough: what matters is what happens on the day a key is lost or compromised, and how quickly.

Our commitment

Within 24 hours of a problem being identified, the affected key is withdrawn from Sekervia.

Within 72 hours, a fixed and signed version ships through the automatic update.

A withdrawn key is permanently rejected, even if an old copy of the application or a package still presents it: Sekervia keeps a list of withdrawn keys and checks it before any other verification.

What we do, step by step

1. Detect — an automatic check verifies, for every release, that each add-on shipped is signed by a key currently in force. A badly executed rotation makes it fail.

2. Create a new key — its private part is secured immediately, before any signing.

3. Replace, not add — the old key is removed from the application and added to the list of withdrawn keys.

4. Re-sign every official add-on with the new key.

5. Prove — the tests verify that no add-on carries a withdrawn key, and that a withdrawn key is never put back into service.

6. Distribute the fixed version through the signed update.

7. Inform — the release notes name the withdrawn key, the date and the reason. An add-on still signed with it no longer loads: this is intentional.

What has already happened to us

On 22 September 2026, while trying to re-sign an add-on, we found that the private part of one of our keys, created on 4 September, had been lost: it had never been secured. A new key was put into service, the add-ons were re-signed, and the old key was withdrawn within minutes. No add-on was signed by a third party.

But the loss was only noticed 18 days after the fact, because nothing checked that the key still existed. That is why step 2 now requires the key to be secured before any signing.