# Mozilla's Signing Key Slip: What the Revocation Certificate Actually Says
When Mozilla announced last week that it had rotated the cryptographic signing key for Firefox and Thunderbird on Linux, the framing was careful and calm. A key ended up in a private repository by mistake. No evidence of external access. The revocation is precautionary. Move along.
The revocation certificate tells a different story.
## The Reason Code Nobody Mentioned
OpenPGP's RFC 4880 gives key owners four numbered reasons to revoke a key. Reason 0 is "no reason specified." Reason 1 means the private key material was compromised. Reason 2 means "key material has been compromised." Reason 3 is for a superseded key. Reason 4 is a key that's no longer used.
Mozilla used reason code 2.
That distinction is not cosmetic. Under RFC 4880's semantics, reason codes 0, 3, and 4 leave all previous signatures made by that key intact and valid. Reason code 1 and 2 — compromise — retroactively cast doubt on every signature the key ever produced. That's why anyone who imports the revocation will find that older Firefox and Thunderbird downloads no longer verify. The revocation certificate, generated August 6 at 11:14 UTC, carries the note "We no longer trust this key."
Mozilla's public post describes this effect but attributes it only to "the nature of GPG signing," stopping well short of acknowledging the signal embedded in the revocation reason itself. Whether that framing is intentional PR hygiene or simply a gap in the disclosure is something only Mozilla knows. Either way, it's the part of this story that deserves more attention than it's received.
## Private Repo Is Not Key Storage
Set aside the revocation semantics for a moment. The underlying incident — a plaintext copy of a private signing key committed to a code repository — is a category of mistake that the industry has catalogued exhaustively and keeps making anyway.
Private repositories are not secure key stores. They have a broad and often expanding access list. They integrate with CI/CD systems, third-party tooling, bot accounts, and contractors whose off-boarding may lag their departure. They're indexed by code search features that don't always respect scope boundaries. They're cloned to developer laptops, some of which aren't MDM-enrolled. A key that exists in a private repo exists on every clone of that repo, across every machine that ever pulled it.
Mozilla says a review of audit logs found no unauthorized access, and that everyone who could see the repository had legitimate access anyway. That's a reasonable response — and also precisely the argument you'd make if the risk was theoretical. The problem is that "everyone with access was authorized" is not the same as "the key was handled with the care appropriate to code signing infrastructure." Authorized employees get phished. Authorized contractors get compromised. Laptops get stolen.
Mozilla has declined to say which repository held the key, how long it sat there, how it was discovered, or what safeguards it has added since. That opacity is frustrating. Seven months early is notable. This is the first revocation in a key chain that goes back to 2015, with five prior subkeys all retired cleanly by expiration. Something changed.
## The RPM Problem Is More Annoying Than It Sounds
For the majority of Linux Firefox users — those installing via their distribution's package manager using Mozilla's own RPM repository — this incident may surface as a broken update with a confusing error message.
The issue is that rpm --import can report success while leaving the old key resident in the RPM database. The correct remediation sequence is to explicitly delete the old key by fingerprint, reimport the new one, and then clean the package cache:
sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353
sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg
sudo dnf clean allOn some distributions, dnf handles the transition automatically and prompts the user to confirm the new fingerprint. On others it fails silently or with an error that doesn't obviously point to a key problem. The new subkey — fingerprint 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3, valid until August 2028 — was published Monday. openSUSE users run the same two rpm commands and then zypper refresh.
Debian and Ubuntu users are unaffected. Mozilla's APT repository uses a different key entirely, and .deb is not among the impacted formats.
## One Week After the npm Hijacking
Timing matters in this business. Mozilla's disclosure lands exactly one week after attackers hijacked the GitHub account behind the keyv and cacheable npm packages — widely used Node.js libraries — and pushed versions containing credential-stealing code. That incident hit organizations that had no idea they were consuming those packages transitively.
The through-line here is supply chain trust infrastructure. Signing keys are the mechanism by which users decide whether a piece of software is what it claims to be. When that mechanism fails — or is put under even theoretical doubt — the entire verification chain unravels. It doesn't matter how good the software is if users can't confirm they got the real thing.
Mozilla, to its credit, moved quickly once the problem surfaced. The revocation happened. The new key is published. The advisory is live. That's the correct response. But the software industry needs to hold itself to a higher standard than "we fixed it when we noticed." Key material sitting in a repository is a policy failure, not a technical accident.
---
## HackWire Analysis
The most significant thing about this incident isn't the accidental commit — those happen — it's the revocation reason code Mozilla chose and the silence around it.
Reason code 2 is the nuclear option in OpenPGP. It tells every client that has ever verified a file signed by this key to reconsider. Mozilla is technically correct that this is "how GPG signing works," but burying that explanation without acknowledging the semantic weight of the reason code feels like incomplete disclosure. The company has framed this as a precautionary rotation. The certificate says something closer to "we no longer trust signatures made by this key." Those are not the same sentence.
This also fits a broader and increasingly visible pattern: organizations are discovering that their internal key management practices weren't designed to survive the surface area of modern development infrastructure. Private repos have become catch-all locations for everything from deployment scripts to secrets to, apparently, code signing keys. The migration to developer platforms has expanded the attack surface around secrets without a corresponding investment in secrets hygiene.
For defenders and DevOps teams reading this: audit your repositories now. Not someday. Not next quarter. Use git-secrets, trufflehog, or GitHub's built-in secret scanning to sweep for key material in both private and public repositories. Implement branch protection rules that require secret-scanning checks before merge. And treat code signing keys the same way you treat production TLS private keys — hardware security modules, not flat files, not environment variables, and absolutely not committed anywhere.
The question every organization should be asking themselves isn't "did Mozilla screw up?" It's "what's sitting in our private repos right now that we haven't audited in two years?"
— HackWire Editorial
---
## Related Coverage