DEV TOOLS Signal 445
Mozilla revokes Firefox signing key after unencrypted copy lands in GitHub
↗
Mozilla revoked a Firefox and Thunderbird signing subkey after it was accidentally committed unencrypted to a private GitHub repository.
The incident shows how a single lapse in secret handling can undermine software integrity verification, even when no unauthorized access is detected. Engineers must review their own secret-management practices to prevent similar exposure. The response also illustrates the operational steps required when a signing key is rotated.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The exposed GPG private subkey was used to sign Linux tarballs, RPM packages, and checksum files for Firefox and Thunderbird releases.
Audit logs revealed no evidence of unauthorized access, but Mozilla added safeguards to prevent a repeat.
Most end users need no action; those who manually verify signatures or use Mozilla’s RPM repository must import the new key and revocation, with older releases failing verification after the revocation.
THE READ
What the cluster adds up to.
Mozilla discovered that an unencrypted copy of a GPG private subkey had been committed to a private GitHub repository accessible only to a limited set of employees. The key was immediately revoked and replaced with a new subkey to restore the integrity of the signing process. This action was taken despite the absence of any detected misuse.
The revoked subkey had been responsible for creating signatures that allow users and package managers to verify that Firefox and Thunderbird binaries have not been altered. Mozilla’s internal audit showed no sign of unauthorized access while the key was exposed, but the company still introduced additional controls to reduce the chance of similar accidents.
For the majority of users who obtain Firefox or Thunderbird through standard channels, the key rotation requires no manual steps. Individuals who perform manual GPG signature verification must import the new subkey and the revocation notice for the old one. Users who rely on Mozilla’s RPM repository may need to manually update their trusted key, particularly on older distribution releases, after which verification of any previously signed artifacts will fail.
The episode underscores the risk of storing cryptographic secrets in source control, even in private repositories. It highlights the importance of automated secret detection, strict access reviews, and clear procedures for key rotation and revocation. Engineering teams should treat this as a reminder to audit their own credential storage and verification workflows.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER