Mozilla vervangt GPG-sleutel voor Firefox en Thunderbird na lek op GitHub

Mozilla heeft een nieuwe GPG-sleutel aangemaakt voor het ondertekenen van Firefox- en Thunderbird-bestanden. De oude GPG-sleutel was onversleuteld uitgelekt in een privé-GitHub-repository. Mozilla heeft geen bewijs van misbruik van de sleutel gevonden.

Wat is GPG?

GNU Privacy Guard, ook wel GPG, is software waarmee gebruikers berichten en bestanden kunnen versleutelen en digitaal ondertekenen. Dat gebeurt met een sleutelpaar dat een geheime en een publieke sleutel bevat. De leverancier gebruikt de geheime sleutel om bestanden digitaal te ondertekenen. Met de publieke sleutel kunnen gebruikers verifiëren of het bestand daadwerkelijk afkomstig is van de juiste leverancier.

Mozilla gebruikte de GPG-sleutel voor het ondertekenen van Linux-tar-bestanden, rpm-packages en checksumbestanden. Deze belandde per ongeluk in een privé-GitHub-repository. Hoe dat precies kon gebeuren, is niet duidelijk.

Mozilla heeft geen bewijs dat de sleutel is misbruikt. Volgens de Firefox-ontwikkelaar had slechts een kleine groep binnen Mozilla toegang tot de repository. Die groep had via andere kanalen al 'geautoriseerde toegang' tot de sleutel.

Het bedrijf zegt extra beveiligingsmaatregelen te treffen om toekomstige lekken te voorkomen. Het is niet duidelijk om welke maatregelen het gaat.

Gebruikers die GPG-handtekeningen handmatig verifiëren, moeten de nieuwe ondertekeningssleutel en de intrekking van de oude sleutel zelf importeren. Ook bepaalde gebruikers van rpm-packagemanagers moeten actie ondernemen. Dat geldt voor gebruikers van Red Hat Enterprise Linux (RHEL), Rocky en Almalinux, op SUSE en openSUSE gebaseerde distro's en oude versies van Fedora. Zij moeten de sleutel zelf vervangen. Bij gebruikers van Fedora 43 of nieuwere versies doet packagemanager dnf dat automatisch.

Reacties (6)

[Llopigat]

Tja zo'n belangrijke sleutel hoort gewoon in een HSM te zitten. Dan kan dit niet gebeuren. Raar dat Mozilla dit niet doet.

[Travelan]

Natuurlijk doen ze dat waarschijnlijk wel, maar als jij als werknemer even copy-paste doet in je vibecode project, en dat op Github knalt...

[starquake]

Bij een HSM kan je dingen laten signen zonder dat je weet hebt van de private key. Dus dat zou dat probleem hebben voorkomen. Maar een HSM implementeren in je buildstraat daar kleven wel heel wat onpraktische problemen aan. Dus waarschijnlijk is dat de reden dat geen HSM gebruikt wordt. Veiligheid staat vaak tegenover flexibiliteit.

EDIT: Het gaat om een sub-key dus misschien staat de key wel in een HSM.

[Reactie gewijzigd door starquake op 11 augustus 2026 16:29]

[Llopigat]

Nee zo werkt dat niet. De private key wordt berekend door de HSM zelf en kan die niet verlaten.

Je kan de HSM alleen vragen om dingen te ondertekenen, maar niet de sleutel er uit halen.

Een HSM kan een hele server zijn (op het werk hebben we die van Thales), of zelfs maar een heel klein chipje. Bijvoorbeeld een Yubikey bijvoorbeeld is ook een soort HSM (en ze maken ook een HSM versie).

[Reactie gewijzigd door Llopigat op 11 augustus 2026 16:49]

[sdziscool]

heel leuk in theorie, maar een failure op de HSM en je hebt geen keys meer, daarvoor moet je redundant zijn en... ohja nu mag je de key plaintext van de een naar de ander overzetten en is hij dus niet exclusief op 1 plek geweest.

majority multisig is nog mogelijk maar daar is de huidige infra absoluut niet op gemaakt.

[Llopigat]

Dat soort dingen zijn helemaal prima te regelen met een goede HSM hoor (waar Mozilla zeker voldoende geld voor heeft).