Mozilla heeft de cryptografische signing key achter downloads van Firefox en Thunderbird op Linux ingetrokken. De reden: een (ongecodeerde) kopie van de sleutel is naar verluidt per ongeluk gecommit naar een van Mozillas eigen private code repositories. Daarmee is de betrouwbaarheid van de bestaande signaturen voor oudere pakketten komen te vervallen.
In deze update leggen we uit wat de Firefox Linux signing key precies doet, waarom intrekking impact heeft op oudere downloads en welke stappen je mogelijk moet nemen, afhankelijk van je installatie- of verificatiemethode.
Wat doet de Firefox Linux signing key?
Wanneer je Firefox voor Linux downloadt (bijvoorbeeld als tarball) wil je kunnen controleren of het bestand echt afkomstig is van Mozilla en niet is aangepast. Daarvoor gebruikt een gebruiker—of een Linux-distributie die verpakt—OpenPGP-signaturen.
De signing key is dus een soort “handtekening” die bevestigt dat de gedownloade Firefox tarball door Mozilla is ondertekend. Als Mozilla de sleutel intrekt, kunnen signaturen die met de oude sleutel zijn gemaakt, na import van de revocation niet langer als vertrouwd worden beoordeeld.
Waarom is intrekken van de signing key niet alleen voor de toekomst?
Intrekking betekent niet automatisch dat bestaande bestanden ineens “kwaad” zijn. Maar het effect op controlemechanismen is wél direct: zodra je de revocation importeert, stoppen bestanden die ooit met de oude sleutel zijn ondertekend met verificatie.
Mozilla geeft aan dat dit geldt voor oudere Firefox en Thunderbird downloads én dus niet beperkt blijft tot downloads die je in de toekomst nog gaat ophalen. Voor wie alleen “standaard” via automatisering installeert, is de impact vaak klein, maar voor mensen die handmatig controleren kan dat anders uitpakken.
Wat Mozilla zegt: geen aanwijzingen voor misbruik
Mozilla stelt dat er geen signalen zijn dat derden de sleutel daadwerkelijk in handen hebben gekregen. De repository was privé en, volgens Mozilla, had niemand zonder legitieme toegang de informatie kunnen inzien. Toch kiest Mozilla er voor om de key te intrekken zodra een incident is vastgesteld.
Die aanpak sluit aan bij het uitgangspunt van OpenPGP: als je niet langer zeker bent van de vertrouwensketen, behandel je de sleutel alsof die mogelijk gecompromitteerd is—ook als je niet publiek kunt bewijzen dat iemand misbruik heeft gemaakt.
Welke nieuwe sleutel en revocation worden gebruikt?
Mozilla publiceerde een vervangende subkey. De fingerprint die erbij hoort is:
827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3
Deze nieuwe subkey heeft een geldigheid tot 5 augustus 2028. Daarnaast draait het incident om een subkey revocation (een intrekking van een onderdeel van de sleutelset), niet om het volledig verdwijnen van de primaire key.
De revocation is door Mozilla voorzien van een reason code die aangeeft dat key material is gecompromitteerd. In de berichtgeving wordt ook een tijdstip genoemd waarop de revocation is gegenereerd en de mededeling “We no longer trust this key” is toegevoegd.
Wat betekent dit voor jou: download controleren of systeembeheer
De meeste Firefox- en Thunderbird-gebruikers hoeven volgens Mozilla niets te doen. Maar er zijn twee scenario’s waarin je wél aandacht moet hebben.
1) Je controleert handmatig de signaturen
Controleer je zelf de handtekeningen van downloads? Dan moet je doorgaans:
- de nieuwe sleutel importeren
- en voor de oude sleutel ook de revocation importeren
Doe je dat niet, dan kan je verificatietool wellicht nog inconsistenties geven. Doe je het wél, dan zal verificatie van oudere bestanden met de oude signing key stoppen—dat is precies het beoogde effect van een revocation.
2) Je installeert via RPM-pakketten
Gebruikers die Firefox via Mozilla’s RPM packages installeren, kunnen te maken krijgen met een mislukte update. Dan moet je mogelijk handmatig een key-wissel uitvoeren.
Mozilla noemt dat sommige distributies dit proces automatisch afhandelen (dnf haalt dan de update op en vraagt je om de fingerprint te bevestigen). Bij andere systemen kan het misgaan, bijvoorbeeld doordat de distributie merkt dat de geïmporteerde key niet helpt of doordat er een mismatch ontstaat tussen geïnstalleerde repository keys en de package set.
Om dit te herstellen beschrijft Mozilla een volgorde waarin eerst de oude key wordt verwijderd en daarna de nieuwe signing key wordt geïmporteerd, inclusief opschonen van caching.
Voorbeelden van herstelstappen op RPM-systemen
Mozilla verwijst naar een aanpak waarbij de oude key eerst volledig wordt verwijderd voordat je een nieuwe key importeert. Waarom? Omdat een import “succes” kan melden, terwijl de verouderde sleutel nog steeds aanwezig blijft—en je pakketverificatie daardoor blijft falen.
Een voorbeeld van de commando-volgorde die in de berichtgeving terugkomt:
- oude key verwijderen
- nieuwe signing key importeren via het Mozilla keypad
- dnf cache opschonen
Welke exacte sleutel-ID’s je gebruikt, hangt af van wat er in jouw omgeving is geïnstalleerd. De update gaat in elk geval over het vervangen van de subkey die wordt ingetrokken en het verwerken van de revocation.
Voor Thunderbird zijn geen officiële RPM’s genoemd, waardoor die stap voor dat product niet standaard van toepassing is. Wel wordt vermeld dat openSUSE gebruikers vergelijkbare rpm-opdrachten uitvoeren en vervolgens de repositories verversen.
APT en .deb: niet hetzelfde sleutelpad
In het nieuwsitem wordt ook benadrukt dat er waarschijnlijk onderscheid is tussen repository’s voor verschillende pakketformaten. Mozilla geeft niet expliciet aan wat er gebeurt met de APT repository voor Debian/Ubuntu-gebruikers, en er wordt gesteld dat .deb niet onder de beïnvloede formats zou vallen.
Met andere woorden: als jij werkt met APT en .deb-pakketten, is de impact mogelijk anders dan bij RPM. Toch blijft het verstandig om je repository keys en updates regelmatig te controleren, zeker als je in je organisatie software centraal beheert.
Waarom OpenPGP reason codes ertoe doen
Een sleutelintrekking (revocation) is niet “alleen administratief”. In OpenPGP kan de eigenaar van een sleutel een machine-leesbare reden meesturen. In de broninformatie wordt een reason code gebruikt die aangeeft dat key material is gecompromitteerd.
Het belangrijke verschil zit in hoe OpenPGP omgaat met verleden signaturen. Als een sleutel gewoonweg is vervangen door een nieuwere (superseded of retired), kunnen oude signaturen onder bepaalde omstandigheden nog valide blijven. Maar bij een revocation wegens mogelijke compromise moet je alle eerder gesigneerde bestanden als verdacht beschouwen—ook als het incident niet aantoonbaar is geweest.
Extra context: supply chain blijft een doelwit
Deze melding komt niet uit de lucht vallen. In dezelfde nieuwsupdate wordt gewezen op een eerdere aanval waarbij criminelen accounts rondom pakket- en code-infrastructuur (zoals GitHub en cacheerbare npm-packages) hebben misbruikt en een worm publiceerden die informatie kan verzamelen uit repositories, registries, cloud en private key-materiaal bij ontwikkelaars en CI-pipelines.
Voor organisaties is dat een reminder: ook als een incident “alleen” intern gebeurt (zoals een private repo), kan de impact op vertrouwen en verificatie groot zijn. Daarom verschuift de focus in software supply chain security vaak naar striktere sleutelhygiëne, audits en duidelijke procedures rond sleutelrotatie en revocation.
Praktische checklist voor IT-teams
Heb je beheerrollen of controleer je zelf softwarebronintegriteit? Gebruik deze punten als snelle leidraad:
- Check je methode van verifiëren: handmatig signaturen of via systeembeheer tooling?
- Werk repository keys tijdig bij (zeker bij RPM-omgevingen) zodat revocations verwerkt worden.
- Beoordeel welke distributies afwijken in gedrag bij key updates (dnf kan automatisch, andere tools mogelijk niet).
- Documenteer je procedure voor key swaps en revocation imports, zodat je sneller kunt handelen bij een volgende update.
Wil je meer lezen over hoe aanvallen via supply chain en tooling kunnen doorwerken? Dan is dit artikel relevant: BdThemes supply chain aanval via JSON: wat je moet weten.
Conclusie
Mozilla heeft de Firefox Linux signing key ingetrokken nadat een kopie van de sleutel per ongeluk in een private repository terechtkwam. Het gevolg is dat verificatie van oudere Firefox- en Thunderbird-downloads kan stoppen zodra je de revocation verwerkt.
Voor de meeste gebruikers is er weinig aan de hand, maar wie handmatig controleert of Firefox via RPM’s beheert kan acties moeten ondernemen: nieuwe key importeren en de juiste revocation verwerken, of bij updates handmatig een key-wissel doen. In een wereld waarin software supply chain steeds vaker wordt aangevallen, blijft dit soort sleutelbeheer een kernonderdeel van betrouwbare softwaredistributie.
Bron: https://thehackernews.com/2026/08/mozilla-revokes-firefox-and-thunderbird.html
