Glonce

Mozilla rotates GPG signing key for Firefox and Thunderbird after leak

securityThe Glonce editorsHacker News🔥50Glonce rating50Impact35Novelty20Relevance60Surprise25Players45Credibility87

Mozilla has moved to a new GPG signing subkey used to sign certain Firefox and Thunderbird release artifacts, specifically Linux tarballs, RPM packages and checksum files. The change followed the discovery that an unencrypted copy of the previous signing subkey had been inadvertently committed to a private GitHub repository. Mozilla says its review of available audit records found no evidence that the key was accessed by an unauthorized party while it sat in the repository, and that access to that repository was limited to a small group within Mozilla, all of whom already had authorized access to the key through other means. The previous signing key has been revoked, and Mozilla says it has added safeguards to prevent similar incidents.

Mozilla states that for most users no action is required. Two groups need to do something. Anyone who manually verifies Mozilla's GPG signatures needs to import the new signing key along with the revocation for the old one. Anyone using Firefox RPM packages may need manual intervention, described below; Thunderbird has no official RPM packages, so no RPM-specific action applies to it.

For RPM users, the required steps depend on the distribution. On Fedora 43 and later, dnf will download the updated key automatically during the next update and only needs the import confirmed; Mozilla advises checking that the shown fingerprint matches 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3 before accepting. On Fedora 42 and older, and on RHEL, Rocky Linux and AlmaLinux, dnf cannot replace the key on its own, and updates will fail with errors such as 'Import of the key didn't help, wrong key?' or a message that the listed keys are not correct for the package; the old key has to be removed manually with 'sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353', followed by importing the new key from Mozilla's packages server and running 'sudo dnf clean all'. openSUSE and SUSE-based distributions need the same manual removal, since zypper also will not replace the key on its own; failures there show as 'Signature verification failed' or 'NOKEY', and the fix uses the same rpm removal and import commands followed by 'sudo zypper refresh'. Mozilla warns that the old key must be removed before the new one is imported: running rpm --import while the old key is still installed can report success even though the key was not actually updated.

The primary GPG fingerprint for Mozilla Software Releases is 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353, and the new signing subkey's fingerprint is 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3; the new subkey expires 2028-08-05. The new public key and the revocation for the previous one are available from the KEY files of the latest Firefox Nightly build, from keys.openpgp.org, or inline in Mozilla's post. Because of how GPG signing works, releases signed with the previous key will no longer be verifiable once the revocation is imported.

Key facts

  • Mozilla rotated the GPG signing subkey for Firefox and Thunderbird release artifacts (Linux tarballs, RPM packages, checksum files) after an unencrypted copy of the previous subkey was accidentally committed to a private GitHub repository.
  • Mozilla's audit review found no evidence the key was accessed by an unauthorized party while exposed, and says repository access was limited to Mozilla staff who already had authorized access to the key through other means.
  • The previous signing key has been revoked; the new signing subkey's fingerprint is 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3 and it expires 2028-08-05.
  • Fedora 43 and later update the key automatically via dnf; Fedora 42 and older, RHEL, Rocky Linux, AlmaLinux and openSUSE/SUSE require manually removing the old key with rpm before importing the new one.
  • Most users need take no action; only people who manually verify GPG signatures, or who use Firefox RPM packages, need to do anything, and Thunderbird has no official RPM packages so is unaffected by the RPM steps.

Why it matters

A code-signing key is one of the strongest trust anchors a software vendor has: whoever holds it can produce artifacts that look authentically signed. Mozilla found an unencrypted copy of the private subkey used to sign Firefox and Thunderbird Linux tarballs, RPM packages and checksum files sitting in a private GitHub repository, and responded by revoking the exposed key and switching to a new one rather than waiting to see if it was ever misused.

Who it affects

Most Firefox and Thunderbird users are unaffected and need to do nothing. The people who do need to act are those who manually verify Mozilla's GPG signatures, who must import the new key and the revocation for the old one, and Firefox RPM package users on Fedora 42 or older, RHEL, Rocky Linux, AlmaLinux, or openSUSE/SUSE, who must manually remove the old key before their package manager will accept updates again. Thunderbird has no official RPM packages, so the RPM-specific steps do not apply to it.

How to use it

Fedora 43 and later handle the rotation automatically: dnf downloads the updated key on the next update and just needs the import confirmed, after checking the fingerprint matches 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3. On older Fedora releases, RHEL, Rocky, AlmaLinux and openSUSE/SUSE, remove the old key first with 'sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353', then import the new key from https://packages.mozilla.org/rpm/firefox/signing-key.gpg, then run 'sudo dnf clean all' (or 'sudo zypper refresh' on openSUSE/SUSE). Anyone who verifies signatures manually can fetch the new public key and the old key's revocation from the latest Firefox Nightly's KEY files, from keys.openpgp.org, or inline from Mozilla's post.

How solid is it

This is a first-party disclosure and remediation notice published directly on Mozilla's own security blog, describing Mozilla's own infrastructure and its own audit review. Mozilla is explicit about the limits of that review: it found no evidence of unauthorized access in the audit records it had available, which is a statement about what was checked rather than a guarantee that no misuse occurred.

Risks and caveats

Once the revocation for the old key is imported, releases previously signed with that key will no longer be verifiable, so RPM users must remove the old key before importing the new one; doing it in the wrong order, or running rpm --import while the old key is still installed, can report success even though the key was not actually updated, leaving updates broken with confusing errors. The post does not name who committed the key, how long it sat exposed in the repository, the name of the private repository, or whether anyone outside Mozilla's own audit review was involved in investigating the incident.

“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.”

— Mozilla security blog