Ubuntu 26.10: Rust non basta a rendere sicura la filiera

Una distribuzione Linux può riscrivere in Rust i propri strumenti di base, cambiare l’implementazione della verifica delle firme e introdurre algoritmi resistenti ai computer quantistici. Tutto nello stesso ciclo di rilascio. Ma questo non significa che abbia risolto un unico problema chiamato “sicurezza”. Significa, semmai, che sta intervenendo su punti diversi di una catena in cui basta un passaggio fragile per rendere discutibile la fiducia nell’insieme.

Il 15 ottobre 2026 è arrivata Ubuntu 26.10, Stonking Stingray, una release intermedia supportata fino a luglio 2027. La notizia non è soltanto il kernel 7.3 o GNOME 51. È la decisione di modificare componenti che gli amministratori tendono a considerare parte del pavimento: i comandi usati negli script, gli strumenti crittografici e perfino ciò che il bootloader può interpretare prima dell’avvio del sistema. E quando cambi il pavimento, non basta controllare che il colore sia rimasto lo stesso.

Rust elimina una classe di errori. Non elimina il contratto con gli script

Ubuntu 26.04 LTS aveva già introdotto le uutils coreutils scritte in Rust come scelta predefinita, mantenendo però le implementazioni GNU di cp, mv e rm per compatibilità. Ubuntu 26.10 completa quel passaggio: anche questi tre strumenti vengono migrati. È una modifica molto più interessante di un semplice cambio di linguaggio, perché riguarda operazioni quotidiane su file, directory e dati.

La motivazione tecnica è solida: il Rust sicuro impedisce molte condizioni di corruzione della memoria, tra cui accessi fuori limite e use-after-free. Ma non può dimostrare che un comando abbia lo stesso comportamento in ogni caso limite. Un programma può essere memory-safe e restituire un codice d’uscita inatteso, interpretare diversamente un’opzione o comportarsi in modo diverso con permessi, link simbolici e condizioni di errore. Se uno script amministrativo prende decisioni sulla base di quel comportamento, il rischio operativo rimane.

Non è una critica alla scelta di Rust. È una critica alla scorciatoia mentale secondo cui la sicurezza del linguaggio renderebbe superflui i test di compatibilità. Canonical stessa raccomanda di verificare gli script che dipendono da dettagli sottili dei comandi, soprattutto quelli privilegiati che copiano, spostano o cancellano file.

La stessa distinzione era emersa parlando di Mold riscritto in Rust: cambiare implementazione senza cambiare il contratto osservabile è spesso la parte più difficile. Su un sistema operativo quel contratto viene esercitato da migliaia di script che nessuno ha scritto pensando a una futura sostituzione delle coreutils.

Sequoia, GnuPG e APT: tre nomi che non andrebbero confusi

Il comunicato di lancio presenta la novità come una transizione verso la verifica delle firme dei repository APT con Sequoia PGP, implementazione OpenPGP scritta in Rust. È una direzione interessante per ridurre l’esposizione a errori di memoria nella componente che verifica l’autenticità dei metadati dei repository. Ma bisogna leggere anche le note tecniche della release, che distinguono l’arrivo di Sequoia nell’archivio main dall’obiettivo futuro di farne la toolchain OpenPGP predefinita.

Le note confermano infatti che gpg e gpgv rimangono disponibili in main, mentre sq e sqv sono gli strumenti corrispondenti del nuovo ecosistema. Dire “è arrivato Sequoia” è verificabile. Dire “tutte le operazioni OpenPGP del sistema usano già Sequoia” richiederebbe invece un inventario delle chiamate effettive, delle versioni installate e della configurazione di APT. Le due affermazioni non sono equivalenti.

C’è poi un livello ancora diverso: la firma di un repository non garantisce che il codice sia privo di vulnerabilità. Garantisce, quando tutta la catena di verifica è corretta, che i metadati verificati corrispondano a una chiave considerata attendibile. La domanda cruciale diventa quindi chi gestisce quella chiave, con quale politica viene accettata, come viene revocata e cosa accade quando il repository cambia. È il motivo per cui anche un lockfile non è una prova sufficiente dell’integrità del software: identificare una versione, verificare un artefatto e fidarsi della sua provenienza sono operazioni collegate, non intercambiabili.

Post-quantum ready non significa che ogni firma sia già post-quantum

La formula “post-quantum package signing” è efficace in un annuncio, ma tecnicamente va scomposta. Un algoritmo di firma resistente agli attacchi quantistici è una cosa; una libreria OpenPGP scritta in Rust è un’altra; la migrazione concreta delle chiavi e delle firme dei repository è una terza. Rust non rende un algoritmo crittografico resistente a un computer quantistico. E sostituire una libreria di verifica non dimostra, da solo, che tutte le firme esistenti siano state rigenerate con algoritmi post-quantum.

Ubuntu 26.10 introduce effettivamente capacità post-quantum nel proprio stack, tra cui il supporto a ML-KEM e ML-DSA e aggiornamenti a OpenSSL 4.0 e openCryptoki. Le note di rilascio documentano in modo specifico le integrazioni dei token IBM Z; il dossier di sicurezza Canonical distingue anche la disponibilità degli algoritmi dal loro impiego nei singoli protocolli. Questi fatti sostengono una direzione architetturale. Non autorizzano a dedurre che ogni repository APT, ogni chiave o ogni connessione abbia già completato la migrazione.

Un caso reale mostra perché la policy conta almeno quanto il codice: durante lo sviluppo della 26.10, un bug documentato su Launchpad riguardava il rifiuto, da parte di sqv, di una firma di associazione basata su SHA-1 per un repository di simboli di debug. Non è una prova che il problema persista nella release finale; è un esempio verificabile di cosa può emergere quando una nuova implementazione applica regole crittografiche più severe a materiale storico. Migliorare la policy può rompere un flusso precedente: proprio per questo servono inventario, rotazione delle chiavi e test.

Una catena di fiducia non diventa affidabile perché uno dei suoi anelli è scritto in un linguaggio più sicuro. Diventa verificabile quando sappiamo quali anelli esistono, chi li controlla e come reagiscono agli errori.

Anche togliere codice ha un costo: il caso Secure Boot

La stessa release restringe il GRUB firmato usato nel percorso UEFI Secure Boot. Canonical ha rimosso dal build firmato parser per alcuni filesystem e formati non necessari al percorso di avvio previsto, riducendo il codice eseguito prima che il kernel prenda il controllo. È una scelta sensata: meno superficie di parsing in una fase privilegiata significa meno opportunità per certe classi di vulnerabilità.

Ma la conseguenza è concreta. Secondo la documentazione Canonical, nel GRUB firmato non restano i driver per Btrfs, HFS+, XFS e ZFS, mentre alcune configurazioni di /boot con LVM, RAID software o LUKS non sono più supportate sotto Secure Boot. Questo non significa che tali filesystem o tecnologie scompaiano dal Linux avviato. Significa che cambia ciò che il percorso di boot firmato può leggere. Un dettaglio trascurabile finché non devi riavviare un server con una partizione di boot personalizzata.

Per questo l’aggiornamento va giudicato sulla topologia reale della macchina, non sulla slide della release. Un sistema con installazione standard e uno con catena di avvio modificata non hanno lo stesso rischio. La riduzione della superficie d’attacco è un guadagno, ma la compatibilità è un requisito da verificare, non una nota a piè di pagina.

Quattro verifiche prima di portare la 26.10 in un ambiente operativo

• Inventaria gli script sensibili. Identifica i punti in cui cp, mv e rm gestiscono file critici, permessi, rollback o cleanup. Provali in staging con dati rappresentativi e verifica risultati, exit code e condizioni di errore.
• Verifica la catena APT effettiva. Non fermarti al nome della libreria installata: controlla quali verificatori sono chiamati, quali repository sono configurati, quali chiavi vengono accettate e come vengono gestiti errori e revoche.
• Controlla il percorso di boot. Se usi Secure Boot, verifica layout di /boot, filesystem, RAID, cifratura e procedura di recupero. Il test che conta è un riavvio completo, non soltanto un upgrade che termina senza errori.
• Separa laboratorio e produzione. Ubuntu 26.10 è una release intermedia con supporto fino a luglio 2027. Per macchine con requisiti di stabilità più lunghi, valuta il ciclo LTS e usa la 26.10 per testare oggi le incompatibilità che non vuoi scoprire domani.

C’è anche Myna, la dettatura locale presentata come anteprima tecnologica e non preinstallata nelle note ufficiali. È una novità interessante, ma il punto delicato della privacy dopo la trascrizione merita un ragionamento separato: il fatto che l’audio rimanga sul dispositivo non decide dove finirà il testo nell’applicazione destinataria. Anche qui, il confine di sicurezza è più importante dello slogan.

La misura del progresso è ciò che riesci a dimostrare

Ubuntu 26.10 mette sul tavolo modifiche tecniche importanti: sostituzione delle coreutils, adozione di strumenti crittografici moderni, nuove capacità post-quantum e riduzione del codice nel percorso di avvio. Non sono semplici ritocchi estetici. Proprio per questo meritano un giudizio più severo di “adesso è tutto più sicuro”.

La domanda utile non è se Rust sia meglio di C o se la parola post-quantum suoni abbastanza futuristica. È se, dopo la migrazione, sappiamo dimostrare che i nostri script fanno ancora ciò che devono, che le firme vengono verificate con le policy previste e che le macchine si avviano nei casi reali. Il progresso di un’infrastruttura non si misura dal numero di tecnologie nuove che contiene, ma dalla quantità di comportamento che possiamo verificare senza doverci fidare sulla parola.