SAN FRANCISCO, 11 AUG 2026 — Mozilla has revoked the GPG subkey it used to sign Firefox and Thunderbird release artefacts, after an unencrypted copy of it was committed to one of its own private GitHub repositories.

Nobody appears to have taken it. The repository was private, access was limited to a small group inside Mozilla, and every one of them already held the key legitimately. Mozilla rotated it anyway, which is the correct answer and a more interesting decision than it looks.

What happened

The subkey signed Linux tarballs, RPM packages and checksum files. It did not sign the browser binaries most people install, which is why the practical blast radius is narrow.

Mozilla's own account is unusually plain about what it found: "Our review of available audit records found no evidence that the key was accessed by an unauthorized party while it was present in the repository." And on who could have: "Access to the repository was limited to a small group within Mozilla, all of whom already had authorized access to the key through other means."

What leakedAn unencrypted copy of the release-signing subkey, into a private repo.
What it signedLinux tarballs, RPM packages and checksum files for Firefox and Thunderbird.
Evidence of misuseNone found. Everyone with repo access already had the key legitimately.
New subkey827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3, expiring 2028-08-05.

The old key is revoked and Mozilla says it has "added safeguards to prevent similar issues in the future".

Why rotate a key nobody stole

Because you cannot prove nobody stole it, and a signing key is the one secret where that distinction collapses.

Most exposed credentials can be reasoned about. A leaked database password is bounded by what the database contains and what the logs show. A signing key is different: its whole value is that anyone can verify it and nobody can forge it, and both properties depend on exactly one assumption — that only the holder has ever had it.

Once a copy has existed somewhere it should not, that assumption is no longer provable. It may still be true. "Probably true" is not what a signature is for.

So the decision is not really about this incident's likelihood. It is about whether the guarantee stays absolute or becomes a probability, and the moment it becomes a probability the key has already lost the thing that made it worth having.

The cost falls on the people doing it properly

Which leads to the uncomfortable part. Most users need to do nothing, because the update path verifies itself.

The only people who have to act are the ones who were manually verifying signatures in the first place, by importing the new key and the revocation for the old one. RPM users on older systems have to remove the previous key by hand before importing the replacement.

That is a familiar and slightly perverse pattern. The security-conscious minority who actually check signatures are the only ones inconvenienced by a rotation, while the majority who never check are unaffected. Every rotation quietly taxes the behaviour it is meant to protect, and it is worth naming, because the answer is not to check less.

The real finding is the workflow

An unencrypted signing key reached a source repository. Not through an attack, not through a misconfigured bucket — somebody committed it.

That is the most common way high-value secrets escape, and it survives in mature organisations because the failure is procedural rather than technical. Everyone knows not to commit a key. Keys get committed anyway, because they end up in a working directory during an operational task and a later git add is broader than intended.

The defences are unglamorous and well understood: keys that never exist in plaintext on a filesystem; signing that happens inside a hardware module or a service, so the key can’t be copied; and pre-commit scanning that refuses the commit. Mozilla says safeguards have been added without specifying which.

The instructive detail is that this happened at an organisation with a mature release-engineering practice and a public procedure for rotating exactly this key. Having the runbook is what turned a bad day into a blog post.

What to take from it

If you sign anything — packages, releases, container images, commits — the question this raises is not whether your key has leaked. It is whether you could tell, and how fast you could replace it.

Mozilla went from discovery to a revoked key, a published fingerprint and instructions in a form users could act on. That capability is built in advance or not at all, and the organisations that struggle are the ones for which rotation is a research project undertaken during an incident.

You can run the test this week: if your signing key had to be replaced tomorrow, who would you tell, how would you reach them, and what would break for anyone still using the old one?

What to watch

Whether Mozilla details the safeguards. "Added safeguards" is the least informative sentence in an otherwise candid disclosure, and the specifics are the part other projects could copy.

Whether the revocation propagates cleanly. Revocations are historically the weakest link in the GPG model, reaching only those who refresh their keyring, and a revoked-but-still-trusted key is worse than no revocation because it looks fine.