Mozilla a annoncé ce lundi 11 août 2026 la rotation de la clé GPG utilisée pour signer certaines livraisons de Firefox et Thunderbird, après qu'une copie non chiffrée de la sous-clé précédente a été accidentellement intégrée (« commise ») dans l'un de ses propres dépôts GitHub privés. L'éditeur a révoqué l'ancienne clé par précaution, tout en jugeant le risque d'attaque par chaîne d'approvisionnement faible.

Ce qui s'est passé

Dans un billet publié lundi, Mozilla explique avoir « déplacé » ses signatures vers une nouvelle sous-clé de signature GPG, utilisée pour certains artefacts Firefox et Thunderbird — à savoir les tarballs Linux, les paquets RPM et les fichiers de sommes de contrôle (checksums). La raison : « une copie non chiffrée de la sous-clé précédente a été involontairement commise dans un dépôt GitHub privé ».

L'organisation tient d'emblée à rassurer : « Notre examen des journaux d'audit disponibles n'a révélé aucune preuve que la clé ait été consultée par une partie non autorisée pendant sa présence dans le dépôt. L'accès au dépôt était limité à un petit groupe au sein de Mozilla, qui disposait tous déjà d'un accès autorisé à la clé par d'autres moyens. »

Autrement dit, le cercle de personnes pouvant théoriquement voir la clé exposée correspondait à celles qui y avaient déjà légitimement accès. Le risque qu'un acteur malveillant en ait profité pour signer des installers contrefaits est donc considéré comme minimal — mais Mozilla a révoqué la clé quand même, par principe.

Détail technique : une révocation « code 2 », pas une simple rotation

L'analyse fine du certificat de révocation, publiée aux côtés de la nouvelle clé, est instructive. Comme l'a décodé The Hacker News, la révocation porte le code de raison 2 (« key material has been compromised » — le matériel de clé a été compromis), générée le 6 août 2026 à 11:14 UTC, avec la note explicative : « We no longer trust this key » (« Nous ne faisons plus confiance à cette clé »).

C'est un point important au sens du standard OpenPGP (RFC 4880) : une clé révoquée pour compromission rend suspectes toutes les signatures qu'elle a jamais produites, là qu'une clé simplement « retirée » (superseded) laisserait ses signatures passées valides. Concrètement, dès qu'un utilisateur importe le certificat de révocation, les anciens téléchargements signés avec l'ancienne clé cessent de vérifier — pas seulement les futurs.

Quelques empreintes utiles à retenir :

  • Clé primaire (inchangée) : 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353 — elle reste en place et n'est pas affectée.
  • Sous-clé révoquée : 09BE ED63 F346 2A2D FFAB 3B87 5ECB 6497 C1A2 0256 (créée le 13 mars 2025, devait courir jusqu'en mars 2027).
  • Nouvelle sous-clé : 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3, valable jusqu'au 5 août 2028.

Une rotation sept mois avant l'échéance prévue

Mozilla fait tourner cette sous-clé de signature environ tous les deux ans, précisément pour se prémunir contre une fuite qu'elle ne détecterait pas. L'examen de la clé publique complète, conservée dans le dépôt de signature de Mozilla, révèle cinq sous-clés précédentes remontant à 2015, toutes retirées par expiration — c'est la première révocation jamais enregistrée sur cette clé.

La sous-clé révoquée avait été annoncée en avril 2025 et n'aurait dû expirer qu'en mars 2027. La rotation intervient donc avec environ sept mois d'avance sur le calendrier normal, conséquence directe de l'incident.

Ce qui est concerné… et ce qui ne l'est pas

Sont concernés par la rotation : les tarballs Linux, les paquets RPM et les fichiers de sommes de contrôle de Firefox et Thunderbird.

Ne sont pas concernés :

  • les paquets .deb et le dépôt APT (Debian/Ubuntu), qui utilisent une clé distincte ;
  • les installers Windows et macOS, qui reposent sur des mécanismes de signature propres à chaque système d'exploitation ;
  • Thunderbird côté RPM, puisque le client de messagerie ne publie pas de paquets RPM officiels — aucune action spécifique n'est donc requise de ce côté.

Ce que les utilisateurs doivent faire

Pour la grande majorité des utilisateurs : rien. Les mises à jour automatiques et les canaux de distribution habituels ne sont pas impactés.

Deux catégories doivent toutefois intervenir :

  1. Ceux qui vérifient manuellement les signatures GPG doivent importer la nouvelle clé de signature ainsi que le certificat de révocation de l'ancienne. La nouvelle clé publique et la révocation sont disponibles via les fichiers KEY des builds Firefox Nightly les plus récents et sur keys.openpgp.org.

  2. Les utilisateurs Linux installant Firefox via les paquets RPM peuvent rencontrer un échec de mise à jour et devoir remplacer la clé manuellement. Sur certaines distributions, dnf gère le changement automatiquement en récupérant la nouvelle clé et en demandant confirmation de l'empreinte ; ailleurs, l'import échoue purement et simplement.

Le piège, souligné par The Hacker News : la commande rpm --import peut signaler un succès tout en laissant l'ancienne clé en place. Il faut donc d'abord supprimer l'ancienne clé, puis importer la nouvelle :

sudo rpm -e --allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353
sudo rpm --import https://packages.mozilla.org/rpm/firefox/signing-key.gpg
sudo dnf clean all

Sur openSUSE / SUSE, on exécute les deux mêmes commandes rpm, puis zypper refresh. Mozilla a partagé des instructions détaillées selon la distribution (Fedora 43 et ultérieures, Fedora 42 et antérieures, RHEL/Rocky/Almalinux, openSUSE/SUSE).

Un détail technique notable, visible dans le fichier de clé RPM de Mozilla : contrairement au fichier KEY sibling, cette version RPM n'inclut volontairement pas la révocation de la sous-clé de mars 2025. La raison invoquée : « certaines distributions basées sur RPM ne gèrent pas bien une clé GPG révoquée ». Un compromis pratique entre rigueur cryptographique et compatibilité.

Ce que Mozilla n'a pas dit

Plusieurs questions restent sans réponse dans l'annonce : Mozilla n'a précisé ni quel dépôt GitHub hébergeait la clé, ni pendant combien de temps elle y est restée exposée, ni comment l'incident a été découvert, et ne décrit pas les mesures correctives qu'elle dit avoir mises en place pour éviter qu'un tel cas se reproduise.

Un contexte de chaîne d'approvisionnement tendu

L'annonce intervient une semaine seulement après le piratage du compte GitHub derrière les paquets npm keyv et cacheable, à la suite duquel un ver a été publié pour récolter secrets, clés privées et identifiants cloud sur les machines de développeurs et dans les pipelines CI. Dans ce contexte de vigilance accrue sur la sécurité de la chaîne d'approvisionnement logicielle, la transparence de Mozilla — révoquer par précaution et communiquer dans la journée — tranche avec les pratiques plus discrètes de certains éditeurs.

La réaction de Mozilla illustre un principe de base de la cryptographie asymétrique : quand un secret de signature est (ou pourrait être) sorti de son périmètre de confiance, on révoque, même sans preuve d'exploitation. La note laconique du certificat — « We no longer trust this key » — résume à elle seule la philosophie : en matière de signature logicielle, le doute ne bénéficie pas à la clé.