Quanto tempo passa tra l'uscita di una patch del kernel e il momento in cui gira davvero sui vostri server? Per chi usa Ubuntu, Canonical ha appena accorciato la prima parte di questa attesa. La seconda parte resta compito vostro.
Cosa cambia
Finora i kernel stabili di Ubuntu seguivano due cicli: uno di aggiornamento regolare da quattro settimane e uno di sicurezza da due. Dal 28 settembre ne resta uno solo, da due settimane. Nella prima settimana si costruiscono i pacchetti, si fanno i controlli di avvio e si pubblica tutto nel repository -proposed, il canale «di prova». La seconda settimana serve alla certificazione hardware e ai test di regressione, cioè a verificare che la correzione non rompa altro. Seguono due cicli di rodaggio, avviati il 28 settembre e il 12 ottobre. Dal 26 ottobre i cicli si sovrappongono e ne parte uno nuovo ogni settimana. In pratica esce un kernel stabile alla settimana.
Perché adesso
Il motivo dichiarato è il numero di CVE, gli identificativi pubblici delle vulnerabilità. Le spinte sono due. La prima: strumenti di intelligenza artificiale trovano bug più in fretta di quanto un team riesca ad analizzarli. Un esempio è CopyFail, scoperta da un'AI quest'anno e diventata una tecnica di escalation dei privilegi. La seconda: da febbraio 2024 è kernel.org ad assegnare le CVE del kernel, con un criterio largo. Quasi ogni bug viene trattato come un possibile problema di sicurezza. Il 22 settembre un solo aggiornamento del kernel Azure di Ubuntu ne correggeva più di 1.400.
Cosa significa per chi gestisce server
Molte di quelle CVE non riguardano la vostra macchina, perché toccano driver o configurazioni che non usate. Altre però sono già sfruttate in attacchi reali, e per distinguerle serve tempo. Chi ha fretta può installare i kernel da -proposed già dopo la prima settimana, ma allora i test li deve fare lui. Per le falle gravi Canonical promette mitigazioni temporanee o indicazioni di hardening entro 24-48 ore dalla divulgazione. Sono toppe e non sostituiscono l'aggiornamento. C'è poi un dettaglio pratico: un kernel nuovo di solito diventa attivo solo dopo un riavvio, a meno di usare il live patching dove è disponibile.
💬 Il mio commento
Il collo di bottiglia, secondo me, non è mai stato Canonical. Gli aggiornamenti arrivavano anche prima. Il problema è il riavvio. Mi capita spesso di lanciare
uname -rsu server che hanno gli aggiornamenti automatici attivi da anni e di trovare un kernel di otto mesi fa. I pacchetti erano installati, ma nessuno ha riavviato perché «quella macchina non si può fermare». Intanto il file/var/run/reboot-requiredresta lì, paziente, da mesi. Con NIS2, poi, rispondere «l'aggiornamento era installato» non basta più: conta cosa gira davvero in memoria.Con un kernel a settimana questa abitudine non regge più. Serve una finestra di manutenzione fissa e un'infrastruttura che sopporti il riavvio di un nodo senza drammi. Non è banale. Nelle piccole aziende con un solo server che fa tutto non ho una ricetta pulita: ci sono solo compromessi tra live patching, finestre notturne e un po' di pazienza. Sul
-proposedin produzione sarei prudente: ha senso con un ambiente di test serio, altrimenti si finisce a fare da collaudatori senza rete. Questa notizia, in fondo, racconta una cosa semplice. Chi trova i bug è diventato più veloce, chi li corregge si sta adeguando, e l'anello rimasto indietro è quasi sempre il riavvio.