Debian 12 è in LTS dall'11 luglio e il tuo VPS non se ne è accorto

L'11 luglio 2026 Debian 12 bookworm è passata al supporto Long Term Support, che la accompagnerà fino al 30 giugno 2028. Lo stesso giorno è terminato il supporto di sicurezza standard, poco più di tre anni dopo la release del 10 giugno 2023. Se gestisci uno o più VPS su bookworm, con ogni probabilità non ti sei accorto di nulla, ed è questo il punto: nessun banner al login, nessun cambio negli URL dei repository, apt update && apt upgrade continua a scaricare pacchetti come ha sempre fatto. Sotto la superficie, però, è cambiata una cosa sostanziale: chi produce quegli aggiornamenti. La manutenzione di bookworm non è più in carico al security team ufficiale di Debian ma al progetto LTS, una struttura di volontari e aziende sponsor che opera con regole, priorità e coperture diverse. Sui VPS che amministro il censimento post-passaggio ha richiesto una mezza giornata, e su più di una macchina ha fatto emergere pacchetti che dall'11 luglio non ricevono più fix di sicurezza senza che nessun comando lo avesse segnalato. In questo articolo scendo in profondità su un concetto solo, cosa significa davvero "essere in LTS", perché è da lì che discendono tutte le decisioni operative: cosa verificare sul VPS, cosa fare delle immagini debian:12 nelle pipeline, e quando programmare il salto a Debian 13.

Cosa significa davvero che Debian 12 è passata in LTS?

La risposta secca: significa che dall'11 luglio 2026 gli aggiornamenti di sicurezza di bookworm sono prodotti dal progetto Debian LTS, non dal security team ufficiale, e che questa copertura durerà fino al 30 giugno 2028, con un perimetro di pacchetti più stretto di quello del supporto standard. Come spiega la pagina ufficiale del progetto LTS, l'iniziativa non è gestita dai team Security e Release di Debian: è un passaggio di responsabilità a un gruppo di manutentori pagati in parte da aziende che hanno interesse a estendere la vita della distribuzione.

La conseguenza pratica più importante sta in una frase che sulla wiki passa quasi inosservata: il numero di pacchetti effettivamente supportati dipende dal livello di finanziamento che il progetto riceve. Il supporto standard copre l'archivio; il supporto LTS copre ciò che le risorse permettono di coprire, con priorità ai pacchetti più usati e alle vulnerabilità più gravi. Non è una critica al progetto LTS, che da anni fa un lavoro egregio: è la natura dell'accordo, e va conosciuta perché ribalta il modello mentale con cui un sysadmin ragiona. Con il supporto standard la domanda è "ho installato gli aggiornamenti?"; con l'LTS la domanda diventa "gli aggiornamenti che mi servono esistono ancora?".

In LTS il rischio non è l'aggiornamento che fallisce: è l'aggiornamento che non arriva. E un fix che non arriva non produce alcun errore, nessun log, nessun alert: solo un CVE aperto che nessuno ti segnala.

C'è anche una buona notizia, ed è infrastrutturale: il progetto LTS riusa gli stessi mirror e lo stesso archivio di sicurezza dei team ufficiali. La suite bookworm-security su deb.debian.org/debian-security resta identica, quindi non devi toccare il sources.list, e anche unattended-upgrades continua a funzionare senza modifiche, perché il canale da cui attinge è lo stesso. Le architetture coperte sono i386, amd64, armhf, arm64 e ppc64el: se hai in giro macchine a 32 bit o vecchie board ARM, bookworm LTS le copre ancora, ed è una delle ragioni per cui restare su 12 può essere una scelta e non solo un ritardo.

Nel mio lavoro di gestione di VPS unmanaged per PMI questo genere di transizione silenziosa è esattamente ciò che distingue un'infrastruttura presidiata da una lasciata a se stessa: nel mio profilo professionale trovi come imposto la manutenzione programmata di server Debian e Ubuntu in produzione, dal patching alla pianificazione dei major upgrade.

Quali pacchetti non sono più coperti, e come scoprirlo

Il perimetro reale della copertura non si deduce leggendo gli annunci: si interroga sulla macchina. Debian fornisce un pacchetto dedicato, debian-security-support, che confronta ciò che hai installato con la lista dei pacchetti la cui copertura è terminata, limitata o esclusa:

sudo apt update
sudo apt install debian-security-support
check-support-status

L'output elenca tre famiglie di problemi. I pacchetti con supporto terminato prima della fine del ciclo (succede quando l'upstream smette di rilasciare fix e il backport diventa impraticabile). I pacchetti con supporto limitato, tipicamente browser e motori di rendering, dove la sicurezza viene garantita saltando a versioni upstream più nuove invece che patchando quella di release. E i pacchetti esclusi dal supporto LTS, che con il passaggio di giugno sono la categoria da guardare con più attenzione. In pratica, su una macchina con problemi l'output ha questa forma:

Limited security support for one or more packages

Unfortunately, it has been necessary to limit security support for some
packages.

The following packages found on this system are affected by this:

* Source:chromium
  Details: See README.Debian.security for the security status

Un output vuoto è la risposta che vuoi vedere; ogni riga in più è una decisione da prendere: sostituire il pacchetto, isolarlo, o accettare formalmente il rischio, mettendolo per iscritto.

Vale la pena spendere un paragrafo anche su come sono fatti i fix che continuano ad arrivare, perché il modello è controintuitivo per chi viene da altri ecosistemi. Debian, in LTS come nel supporto standard, non aggiorna i pacchetti alla versione upstream più recente: fa backporting della sola patch di sicurezza sulla versione congelata alla release, incrementando il suffisso del pacchetto (i numeri di versione con +deb12uN che vedi passare in apt list --upgradable). Il vantaggio è che il comportamento applicativo non cambia mai sotto i tuoi piedi; il rovescio è che il numero di versione a monte resta fermo, e uno scanner ingenuo, o un cliente che ti chiede "che versione di nginx avete?", leggerà una versione antica e apparentemente vulnerabile. La risposta corretta si dà con il changelog del pacchetto (apt changelog nginx), dove ogni CVE backportato è tracciato riga per riga: è lì che si dimostra che una versione "vecchia" è in realtà patchata.

L'altro strumento del mestiere è la mailing list debian-lts-announce, dove passano tutti i DLA (Debian LTS Advisory). Ogni advisory dichiara pacchetto, CVE corretti e versione: è il flusso che sostituisce i DSA a cui eri abituato. Iscriversi costa trenta secondi e trasforma l'LTS da scatola nera a canale osservabile; è lo stesso principio che applico nella checklist di emergenza per VPS Debian e Ubuntu unmanaged: la differenza fra incidente e routine la fa quasi sempre ciò che avevi predisposto prima.

E i container debian:12 nelle pipeline?

Il capitolo container merita un ragionamento a parte, perché il modello di rischio è diverso da quello del VPS. La base image debian:12 (e la variante 12-slim) continua a ricevere aggiornamenti: l'archivio bookworm resta vivo e la suite di sicurezza pure, quindi le immagini ufficiali continuano a essere ricostruite e un apt-get upgrade in build continua a portare i fix LTS. Su questo fronte non c'è nessuna emergenza. I punti di attenzione sono altri due.

Il primo: la copertura selettiva vale anche dentro i container. Se la tua immagine applicativa installa pacchetti che check-support-status segnalerebbe come non supportati, il fatto di stare in un container non li rende più sicuri: li rende solo meno visibili, perché nessuno lancia strumenti diagnostici dentro un'immagine. Qui il presidio si sposta sulla pipeline: rebuild periodici programmati (non solo al cambio del codice applicativo) e uno scanner di vulnerabilità sulle immagini, così che un CVE senza fix in bookworm emerga dal report dello scanner invece che da un incidente.

Il secondo è più subdolo e riguarda i tag. Dal rilascio di Debian 13 trixie come stable, ad agosto 2025, il tag debian:latest punta a trixie: se qualche Dockerfile in azienda usa latest, quelle immagini hanno già cambiato major release senza che nessuno l'abbia deciso, e convivono con le debian:12 pinnate esplicitamente. È il classico drift che si scopre al primo comportamento divergente fra ambienti. La regola che applico è banale e non negoziabile: base image sempre pinnata per release (debian:12-slim o meglio debian:bookworm-slim), mai latest, e il passaggio a debian:13 fatto come migrazione deliberata, testata sugli stessi criteri con cui migreresti il VPS. Per gli ambienti dove serve riproducibilità totale, il gradino successivo è il pinning per digest (debian@sha256:...), che congela l'immagine byte per byte: a quel punto però i fix LTS non entrano più da soli nemmeno al rebuild, e il digest va fatto avanzare con un processo esplicito, tipicamente un bot di aggiornamento dipendenze che apre una merge request quando l'immagine ufficiale cambia. Digest pinnato senza processo di avanzamento è il modo più elegante che conosco per costruirsi un parco container perennemente non patchato.

Restare su bookworm o salire a trixie: il criterio di decisione

La finestra LTS ti dà tempo fino al 30 giugno 2028, e il tempo va usato per decidere, non per rimandare. Il criterio che uso per i parchi macchine dei clienti è una matrice a due domande. Prima domanda: la macchina dipende da pacchetti che l'LTS copre male o non copre? Se check-support-status è pulito e il carico è fatto di componenti mainstream (nginx, PHP, MariaDB, PostgreSQL, la solita fanteria), bookworm LTS è un posto ragionevole dove stare anche a lungo. Se invece l'output segnala componenti critici, la migrazione smette di essere procrastinabile. Seconda domanda: cosa costa il fermo? Per la macchina singola con finestra di manutenzione libera, l'upgrade a Debian 13 conviene presto, con la procedura via SSH che ho documentato passo per passo; per il parco eterogeneo conviene scaglionare, portando prima le macchine più esposte e lasciando in coda quelle più stabili, che nel frattempo l'LTS continua a coprire.

C'è poi una terza dimensione, che per chi fa PHP è spesso quella decisiva: lo stack applicativo che la release si porta dietro. Bookworm è uscita con PHP 8.2 nei repository ufficiali, e PHP 8.2 termina il proprio supporto di sicurezza upstream il 31 dicembre 2026. Da gennaio 2027, i fix per il PHP di sistema di bookworm dipenderanno interamente dal lavoro di backporting dei manutentori, senza più patch upstream da cui attingere: un doppio livello di dipendenza che restringe ulteriormente il margine. Se le tue applicazioni girano sul PHP pacchettizzato dalla distribuzione, questo è un argomento concreto per anticipare la migrazione, o quantomeno per disaccoppiare la versione di PHP da quella del sistema operativo; è lo stesso ragionamento sulle scadenze che nel pillar PHP applico alle codebase, qui applicato al layer di sistema.

Un errore che vedo spesso è trattare la scadenza 2028 come "il problema del 2028". I major upgrade fatti bene si pianificano con mesi di anticipo, e su trixie i cambi di comportamento non mancano, come racconto anche nel pezzo sulla point release 13.5 e la gestione degli aggiornamenti su un parco VPS. Arrivare a giugno 2028 con metà parco ancora su bookworm significa fare gli upgrade sotto scadenza, che è il modo migliore per farli male.

La LTS non è un parcheggio: è un prestito di tempo con un piano di rientro. Se il piano di rientro non esiste, non stai usando la LTS, la stai subendo.

La verifica replicabile: cinque comandi, cinque risposte

Chiudo con la diagnosi che puoi replicare adesso su ogni macchina bookworm, con l'esito atteso di ciascun passo. Primo, conferma la release:

cat /etc/debian_version
# atteso: 12.x

Secondo, verifica che la suite di sicurezza sia agganciata (formato classico o deb822 che sia):

grep -rh security /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
# atteso: una riga con debian-security e suite bookworm-security

Terzo, controlla che gli aggiornamenti arrivino davvero:

sudo apt update && apt list --upgradable 2>/dev/null | head
# atteso: nessun errore sui repo; eventuali pacchetti da bookworm-security in lista

Quarto, il censimento della copertura, il passo che quasi nessuno fa:

sudo apt install -y debian-security-support && check-support-status
# atteso: output vuoto; ogni riga elenca un pacchetto con supporto finito o limitato

Quinto, la data di scadenza scritta dove la vedrai: un promemoria in calendario ben prima del 30 giugno 2028, e l'iscrizione a debian-lts-announce per gli advisory. Cinque minuti in tutto, e la transizione silenziosa di giugno torna a essere ciò che deve essere: un evento noto, misurato e sotto controllo.

Se il tuo parco macchine è ancora su bookworm e vuoi trasformare questa finestra LTS in un piano concreto, con il censimento della copertura, la matrice di priorità e il calendario dei major upgrade fatto per stare larghi rispetto al 2028, contattami per una consulenza: tipicamente in una giornata di lavoro usciamo con la fotografia completa del parco e le date di migrazione per ogni macchina.