Updated GPG Key for Signing Firefox and Thunderbird Releases

Mozilla discovered that an unencrypted copy of its previous signing subkey had been committed to a private repository, prompting a revocation of that key and the introduction of a fresh subkey for signing Firefox and Thunderbird artifacts. The incident was limited to internal access, and no unauthorized use of the key was observed. The new subkey comes with a defined expiration date and a new fingerprint that will be used for all future releases.

For developers who manually verify GPG signatures, the immediate task is to fetch the new public key and the revocation notice for the old key, then import them into their keyring. After the import, any signatures generated with the old subkey will no longer validate, which could break scripts that assume continuous verification success. This change does not affect end-users who rely on default package managers, but it does require a deliberate update step for those performing explicit signature checks.

The impact is most visible on RPM-based distributions that do not automatically replace GPG keys. On Fedora 43 and newer, the package manager will prompt for the new key during the next update, requiring only a confirmation of the fingerprint. However, on Fedora 42 and earlier, as well as RHEL, Rocky, and AlmaLinux, the package manager cannot replace the key on its own, leading to update failures unless the old key is manually removed and the new one imported.

OpenSUSE and other SUSE-derived systems face a similar situation because their package manager, zypper, also lacks automatic key rotation. Administrators must explicitly delete the old key, import the new key from Mozilla’s signing-key URL, and refresh the repository metadata to restore normal update operations. Failing to perform these steps will result in signature verification errors such as “NOKEY” or “Signature verification failed.”

Overall, the key rotation introduces a short-term operational overhead for environments that enforce strict GPG verification, but it does not require changes to the software itself. The new safeguards aim to prevent accidental exposure of signing material in the future, reducing the risk of similar incidents. Teams should incorporate the key import commands into their deployment or CI pipelines to automate the transition on affected platforms.