In questo articolo Indice dei contenuti 2 sezioni
Canonical ha deciso di cambiare il modo in cui Ubuntu distribuisce gli aggiornamenti del kernel, con un obiettivo preciso: accorciare il tempo che passa tra la divulgazione pubblica di una vulnerabilità e l’arrivo della correzione sui sistemi degli utenti. Il nuovo kernel Ubuntu potrà così essere pubblicato ogni settimana. La scelta arriva in un momento in cui i problemi di sicurezza scoperti nel codice Linux sono in costante aumento, anche perché gli strumenti basati su Intelligenza Artificiale stanno automatizzando sempre di più la caccia ai bug.
Il nuovo approccio non rinuncia alle verifiche che precedono ogni rilascio. Cambia piuttosto il modo in cui vengono organizzate, facendo scorrere in parallelo cicli diversi. Nella documentazione dell’azienda gli SRU sono descritti come la procedura riservata agli aggiornamenti delle release già pubblicate, con test di regressione eseguiti anche sull’hardware certificato. Il punto della novità sta quindi soprattutto nella frequenza con cui le correzioni possono arrivare a destinazione.
Come funzionano i nuovi cicli SRU del kernel Ubuntu
Fino a oggi lo schema prevedeva un ciclo ordinario di quattro settimane affiancato da uno dedicato alla sicurezza di due settimane. Canonical passa adesso a cicli SRU di due settimane ciascuno, fatti partire a una settimana di distanza l’uno dall’altro. Proprio questa sovrapposizione consente di sfornare un kernel nuovo ogni sette giorni senza schiacciare integrazione, compilazione e controlli nello stesso intervallo di tempo.
La prima fase è quella in cui si integrano le correzioni, si preparano i pacchetti e si realizzano le build. Poi arrivano i controlli preliminari, mentre le versioni candidate finiscono nel repository proposed. La fase successiva si concentra invece sulla certificazione dell’hardware, sull’integrazione con Ubuntu e sui test di regressione. La documentazione ufficiale conferma che queste verifiche servono a controllare il comportamento degli SRU sui sistemi certificati.
Il vero guadagno del nuovo modello è la possibilità di lavorare su più fronti contemporaneamente. Mentre un kernel affronta gli ultimi controlli, quello successivo può già avanzare con la preparazione delle proprie patch. Chi gestisce infrastrutture e non può aspettare la versione stabile ha poi un’alternativa: usare le release candidate disponibili in proposed e sottoporle ai propri test di accettazione. In quel caso però una parte della validazione ricade direttamente sull’organizzazione che sceglie di adottarle.
Perché le vulnerabilità hanno spinto Canonical ad accelerare
L’azienda lega questa svolta alla crescita dei difetti di sicurezza individuati nel kernel. I Large Language Models e gli agenti specializzati hanno reso la ricerca dei bug molto più automatica, e di conseguenza i manutentori si trovano a dover analizzare e sistemare un volume di segnalazioni ben più corposo. L’aumento non dipende però soltanto dall’AI. Dal 2024 la comunità del kernel Linux agisce anche come autorità per l’assegnazione degli identificativi CVE, e questo ha allargato la classificazione di sicurezza a un numero maggiore di difetti in grado di influire su un sistema in funzione.
C’è poi un secondo obiettivo, cioè ridurre la finestra durante la quale una macchina resta esposta dopo che una falla è diventata pubblica. Quando una patch definitiva richiede più tempo, Canonical punta a fornire, dove possibile, soluzioni temporanee sicure oppure indicazioni di hardening. Il traguardo dichiarato è portare i sistemi in una condizione considerata più sicura entro un arco compreso tra 24 e 48 ore dalla divulgazione, senza che queste misure vengano considerate un sostituto dell’aggiornamento definitivo.
Per gli amministratori Ubuntu il cambiamento porta con sé soprattutto una nuova esigenza pratica: valutare in tempi più stretti compatibilità, regressioni e priorità degli aggiornamenti. Un ritmo più serrato può accorciare il periodo di esposizione, ma rende ancora più importante contare su ambienti di test e procedure capaci di intercettare eventuali problemi prima che una nuova build raggiunga i sistemi critici.
Fonte: TecnoAndroid
