In questo articolo Indice dei contenuti 3 sezioni
Un errore di gestione interna ha portato la chiave privata usata da Mozilla per firmare i pacchetti Linux di Firefox e Thunderbird a finire, in chiaro, dentro un repository GitHub della fondazione. Niente furto accertato, niente attacco, ma una svista che ha comunque imposto la strada più prudente possibile, cioè la revoca della vecchia sottochiave e l’introduzione di una nuova. Chi usa Fedora, RHEL, Rocky Linux, AlmaLinux o openSUSE potrebbe accorgersene nel modo più fastidioso, con gli aggiornamenti che si bloccano.
Le firme crittografiche accompagnano da anni la distribuzione del software e nel mondo Linux contano parecchio, perché permettono ad amministratori e utenti di verificare in autonomia da dove arrivano pacchetti, archivi e file di checksum. Mozilla usa infrastrutture di firma diverse a seconda dell’elemento distribuito, e la chiave coinvolta in questa vicenda è quella GPG impiegata per i tarball Linux, i pacchetti RPM e i file con gli hash delle release.
Che cosa è successo alla chiave GPG di Mozilla
Una copia non cifrata della precedente chiave privata di firma è stata inserita per sbaglio in un repository GitHub privato. Le verifiche comunicate dalla fondazione non parlano di compromissione: i log non mostrano accessi da parte di soggetti non autorizzati e il repository era visibile solo a un gruppo ristretto di dipendenti Mozilla che quella chiave già la possedevano legittimamente attraverso altri canali. Il punto, però, è un altro. Quando non si può più garantire con certezza assoluta che una chiave privata sia rimasta confinata nei sistemi previsti, la prassi corretta è revocarla e sostituirla. La revoca è a tutti gli effetti una dichiarazione crittografica, un segnale che dice ai software compatibili con OpenPGP che quella sottochiave non va più considerata valida per verificare nuove firme. Non basta pubblicare una chiave diversa e tirare avanti, serve distribuire anche l’informazione che rende inutilizzabile la vecchia credenziale. OpenPGP consente infatti di costruire l’identità crittografica intorno a una chiave primaria, tenuta più al riparo, a cui si agganciano sottochiavi dedicate alle operazioni quotidiane come la firma dei file.
La chiave pubblica Mozilla Software Releases mantiene il fingerprint 14F2 6682 D091 6CDD 81E3 7B6D 61B7 B526 D98F 0353. Cambia la sottochiave usata per le nuove firme, con fingerprint 827E 6586 0867 9618 CD34 9F93 678E 455D 7676 7AA3 e scadenza fissata al 5 agosto 2028.
Fedora, RHEL e derivate, dove serve un passaggio manuale
Su Fedora 43 e versioni successive la transizione è quasi indolore, perché DNF scarica la chiave aggiornata al primo aggiornamento utile e chiede conferma per l’importazione. Vale una regola che dovrebbe diventare un riflesso: non approvare alla cieca. Il fingerprint serve proprio a controllare che la chiave proposta dal gestore dei pacchetti sia quella annunciata da Mozilla. Nessuna rimozione manuale necessaria, la rotazione la gestisce DNF. Discorso diverso per Fedora 42 e precedenti e per alcune release di RHEL, Rocky Linux e AlmaLinux, dove i gestori dei pacchetti possono non riuscire a rimpiazzare la chiave già memorizzata. Il sintomo è chiaro, con DNF che si ferma segnalando “Import of the key didn’t help, wrong key?” oppure avvisando che le chiavi configurate per il repository Mozilla risultano installate ma non corrette per il pacchetto. La procedura consigliata prevede di rimuovere prima la vecchia chiave con sudo rpm -e –allmatches gpg-pubkey-14f26682d0916cdd81e37b6d61b7b526d98f0353, importare quella nuova con sudo rpm –import https://packages.mozilla.org/rpm/firefox/signing-key.gpg e ripulire la cache con sudo dnf clean all. Attenzione, perché il solo rpm –import lasciando in piedi la chiave precedente può restituire un esito apparentemente positivo senza aggiornare davvero nulla.
openSUSE, SUSE e il valore reale di una firma
Su openSUSE e SUSE il comportamento è analogo, con Zypper che può non sostituire da sé la vecchia chiave e la verifica che fallisce con errori tipo “Signature verification failed” o “NOKEY”. La strada indicata è la stessa eliminazione dal database RPM, poi l’importazione della nuova chiave e infine sudo zypper refresh. Non si sta disattivando la verifica delle firme per far ripartire gli aggiornamenti, si sta aggiornando l’elemento di fiducia usato da RPM.
Un hash come SHA-256 dice soltanto che un file non è cambiato rispetto a un valore di riferimento, non dice chi ha pubblicato quel valore. La firma digitale aggiunge l’autenticazione, e qui si capisce perché la perdita di una chiave privata pesi così tanto: chiunque ne entrasse in possesso potrebbe firmare software malevolo facendolo apparire come autentico.
