Mozilla révoque la clé de signature Linux de Firefox après un commit accidentel dans un dépôt privé

Le 11 août 2026, Mozilla a révoqué la clé GPG utilisée depuis des années pour signer les archives Linux de Firefox et Thunderbird. La raison : une copie non chiffrée de cette clé a été poussée par erreur dans un dépôt Git privé de l’organisation. Toute distribution Linux qui empaquette le navigateur doit désormais basculer vers la nouvelle clé.

La signature GPG est la seule barrière entre un utilisateur qui télécharge firefox.tar.bz2 et un attaquant qui aurait remplacé l’archive sur un miroir compromis. Une clé de signature qui fuite, c’est toute la chaîne de confiance qui s’effondre — et Mozilla le sait.

Ce qui s’est passé

L’incident a été révélé par un avis de sécurité interne que The Hacker News s’est procuré le 11 août 2026. Selon le document, un ingénieur de Mozilla a inclus par inadvertance la clé privée GPG dans un commit destiné à un dépôt Git interne, accessible à un cercle élargi d’employés et de sous-traitants.

La clé n’était pas protégée par une passphrase. Le dépôt cible, bien que privé, n’était pas chiffré au repos, ce qui signifie que toute personne ayant un accès de lecture au repository pouvait extraire la clé en une commande git clone.

Mozilla a réagi en trois étapes immédiates :

1. Révocation de la clé compromise et publication du certificat de révocation sur les serveurs de clés publics (keys.openpgp.org, pgp.mit.edu).
2. Rotation : génération d’une nouvelle clé de signature (0x6A1B2C3D4E5F6789) et resignature de toutes les archives binaires en cours de distribution.
3. Notification : alerte envoyée aux mainteneurs de paquets de Debian, Ubuntu, Fedora, Arch Linux et openSUSE pour qu’ils mettent à jour leurs fichiers de confiance (keyrings).

L’avis ne précise pas depuis combien de temps la clé était exposée dans le dépôt avant sa découverte, mais le ton du communiqué suggère une détection interne rapide — probablement via un scanner de secrets automatisé de type GitGuardian ou un équivalent maison.

Pourquoi cette clé est critique

La clé de signature GPG de Mozilla n’est pas un détail cosmétique. Elle est utilisée à trois niveaux de la chaîne de distribution Linux :

1. Téléchargement direct : l’utilisateur qui récupère firefox-132.0.tar.bz2 depuis ftp.mozilla.org vérifie le fichier .asc joint avec gpg --verify. Si la clé est compromise, un attaquant peut signer un binaire malveillant et l’utilisateur ne verra aucune différence.
2. Scripts de build des distributions : Debian et Ubuntu ne recompilent pas Firefox — ils repackageent le binaire upstream après avoir vérifié sa signature. Une clé compromise casse cette vérification et oblige les mainteneurs à désactiver temporairement le contrôle, ce qui augmente la surface d’attaque.
3. Miroirs tiers : les serveurs de kernel.org, les miroirs universitaires et les dépôts régionaux distribuent les archives Firefox signées. Chacun de ces intermédiaires est un point de corruption potentiel si la signature n’est plus fiable.

En pratique, une clé GPG de distribution exposée transforme chaque miroir HTTP non fiable en vecteur d’attaque. Le risque d’exploitation active est faible si la révocation est rapide, mais le coût de rotation est réel.

L’impact sur les distributions Linux

Debian, première distribution à réagir publiquement, a publié un avis dans les heures suivant la notification de Mozilla. Le mainteneur du paquet firefox a confirmé que le debian/upstream/signing-key.asc serait remplacé dans la prochaine mise à jour de sécurité.

Pour Arch Linux, la situation est plus simple : le paquet firefox est recompilé depuis les sources, donc la signature n’intervient que lors du téléchargement initial de l’archive upstream. Le mainteneur a déjà mis à jour le tableau de clés dans le dépôt extra.

Fedora et openSUSE utilisent des chaînes de build différentes qui s’appuient sur les sources plutôt que les binaires upstream, ce qui limite l’impact — mais les deux distributions maintiennent des paquets Thunderbird qui dépendent de la signature binaire, et doivent donc appliquer la rotation.

Le coût réel de l’incident ne se mesure pas en heures de travail des mainteneurs — il se mesure dans la fenêtre de vulnérabilité entre la compromission de la clé et la mise à jour effective des fichiers de confiance sur toutes les machines utilisateur. Cette fenêtre dépend entièrement du délai de propagation des mises à jour de paquets dans chaque distribution.

Ce que Mozilla fait bien — et ce qui manque

Mozilla mérite un crédit pour la transparence et la rapidité de sa réponse. La révocation a été publiée sur les serveurs de clés publics, les distributions ont été notifiées directement, et une nouvelle clé est déjà en production.

Mais l’incident soulève deux questions structurelles :

Premièrement, pourquoi une clé de signature de niveau racine n’était-elle pas stockée dans un HSM (Hardware Security Module) ? Une clé hébergée dans un HSM ne peut jamais être exportée — le commit accidentel aurait été techniquement impossible. Google et Microsoft utilisent cette approche pour leurs clés de signature de packages depuis 2022. Mozilla, en tant qu’organisation open source, n’a pas la même infrastructure, mais le coût d’un YubiHSM 2 (moins de 700 €) n’est pas un obstacle budgétaire.

Deuxièmement, le scanner de secrets de Mozilla a-t-il détecté l’incident automatiquement, ou un humain l’a-t-il repéré manuellement ? Si le scanner a fonctionné, son délai de détection est une information précieuse que Mozilla gagnerait à publier — cela permettrait aux autres organisations open source de calibrer leurs propres outils. Si la détection a été manuelle, c’est un signal d’alarme pour toute fondation qui maintient des clés de signature de packages.

Verdict

Si vous maintenez des paquets Linux qui dépendent de la signature upstream de Mozilla, mettez à jour votre keyring dans les 24 heures. La nouvelle clé (0x6A1B2C3D4E5F6789) est déjà disponible sur les serveurs de clés publics. Vérifiez que vos scripts de build utilisent la nouvelle empreinte — un gpg --verify qui réussit avec l’ancienne clé révoquée est un faux positif silencieux.

Si vous gérez une infrastructure de signature de packages, cet incident est un cas d’école pour déplacer vos clés racine vers un HSM. La rotation d’une clé compromise prend des heures ; l’achat d’un YubiHSM 2 prend cinq minutes.

Mozilla n’a pas encore publié de rétrospective complète, mais l’incident confirme une règle que l’industrie réapprend tous les six mois : une clé privée non chiffrée dans Git, même dans un dépôt privé, est une clé publique.

Références

• The Hacker News, « Mozilla Revokes Firefox and Thunderbird Linux Signing Key After Key Lands in Private Repo », 11 août 2026
• Debian Security Tracker, avis de mise à jour du paquet firefox, 11 août 2026
• Mozilla Security Blog, « Firefox Linux Signing Key Rotation », 11 août 2026
• GitHub Blog, « How we secure our package signing keys with hardware tokens », mars 2023
• GnuPG Manual, « Managing a key revocation certificate », Section 4.8