Firefox e il problema del certificato che bloccava le estensioni: cosa è successo e la lezione imparata

Vi ricordate del giorno nero di Firefox di qualche mese fa in cui le estensioni del browser hanno smesso di funzionare a causa di un certificato di sicurezza scaduto?

A seguito di quel funesto evento è stata aperta una indagine interna per capire cosa non abbia funzionato all’interno della infrastruttura di Firefox. Ecco le conclusioni.

Il team sapeva

Come è possibile che il team di Firefox abbia lasciato scadere il certificato? A seguito delle indagini svolte è emerso che il team responsabile del sistema che ha generato le firme sapeva che il certificato stava scadendo ma pensava (erroneamente) che Firefox ignorasse le date di scadenza. Parte del motivo di questo malinteso era che in un precedente incidente il team aveva disabilitato il controllo del certificato finale e questo ha causato confusione sullo stato del controllo intermedio del certificato.
Inoltre, il piano di QA di Firefox non includeva test per la scadenza del certificato (o test generalizzati su come il browser si comporterà in date future) e quindi il problema non è stato rilevato.

La morale della favola è…

La lezione imparata dal team di Firefox è che ha bisogno di una migliore comunicazione e documentazione di queste parti del sistema e queste informazioni devono essere ricondotte al team del controllo qualità per assicurarsi che non ci siano lacune.

Come è stato risolto il problema nell’immediato

Come accennato in precedenza, una volta risolto il problema, il team di sviluppo ha deciso di inviare le correzioni tramite la funzionalità Studi di Firefox (chiamata internamente con il nome in codice di Normandia). Il sistema Studi non è una scelta ovvia per questo tipo di situazioni perché era destinato alla distribuzione di esperimenti, non a correzioni di codice. Inoltre, poiché l’autorizzazione degli Studi è accoppiata alla telemetria, ciò significava che alcuni utenti dovevano abilitare la telemetria per ottenere la correzione, portando Mozilla a sovrastimare temporaneamente i dati che non volevano, e che quindi hanno dovuto ripulire.
La domanda nasce spontanea: “non c’era un altro modo con cui distribuire le correzioni di questo tipo?”. La risposta è “una specie”. Il meccanismo principale per distribuire il nuovo codice agli utenti è l’uso delle point-release e un sistema chiamato Balrog. Sfortunatamente entrambi sono più lenti di Normandia: Balrog verifica la disponibilità di un aggiornamento ogni 12 ore (anche se si è scoperto che c’è stato un po’ di confusione sul fatto che questo numero fosse 12 o 24), mentre Normandia controlla ogni 6 ore. Perché c’erano molti utenti che erano affetti da questo problema, riparare il tutto era una una priorità e per questo si è scelto di utilizzare gli Studi.
L’altra lezione imparata è che c’è bisogno di un meccanismo che consenta aggiornamenti rapidi non associati a telemetria e studi. Gli sviluppatori desiderano fornire rapidamente gli aggiornamenti a qualsiasi utente che abbia gli aggiornamenti automatici abilitati e stanno già lavorando su questo.

Correzioni incomplete

Nelle settimane successive all’incidente, sono state rilasciate un gran numero di correzioni, tra cui otto versioni del componente aggiuntivo di sistema e sei point release. In alcuni casi ciò era necessario perché versioni precedenti avevano bisogno di una correzione separata. In altri casi era il risultato di difetti in una correzione precedente, che poi gli sviluppatori hanno dovuto correggere nel lavoro successivo. Naturalmente, i difetti nel software non possono essere completamente eliminati, ma il rapporto tecnico ha rilevato che almeno in alcuni casi un alto livello di urgenza combinato con una mancanza di risorse di QA disponibili (o almeno problemi di coordinamento attorno al QA) ha portato a test che erano meno approfonditi di quanto il team voleva raggiungere.