Su un server Debian il PHP in produzione può arrivare da tre posti diversi: dai repository della distribuzione, dal repository deb.sury.org di Ondřej Surý oppure da pacchetti costruiti apposta. Spesso convivono, perché il server è stato installato con il PHP di Debian e poi, per far girare un’applicazione più vecchia o più nuova, qualcuno ha aggiunto deb.sury.org. Anni dopo, nessuno ricorda più da dove arriva il PHP-FPM che serve il sito, e quindi chi lo sta correggendo.
In questo articolo mettiamo ordine. Vediamo quale PHP include ogni release di Debian e chi lo corregge a ottobre 2026, cosa offre deb.sury.org e quali sono i suoi limiti per le versioni in End of Life, quando ha senso costruire pacchetti propri e quali comandi usare per capire su quale fonte stai contando.
Quale PHP c’è in ogni release di Debian
Come Ubuntu, Debian include un solo ramo di PHP per release, con il numero nel nome dei pacchetti: php7.4-fpm su Debian 11, php8.2-fpm su Debian 12. Il ramo resta lo stesso per tutta la vita della release, anche dopo che il progetto PHP ha smesso di supportarlo.
| Release | PHP incluso | Fine del supporto del team di sicurezza | Fine di Debian LTS |
|---|---|---|---|
| Debian 8 jessie | 5.6 | giugno 2018 | giugno 2020 |
| Debian 9 stretch | 7.0 | luglio 2020 | giugno 2022 |
| Debian 10 buster | 7.3 | agosto 2022 | giugno 2024 |
| Debian 11 bullseye | 7.4 | agosto 2024 | 31 agosto 2026 |
| Debian 12 bookworm | 8.2 | giugno 2026 | 30 giugno 2028 |
| Debian 13 trixie | 8.4 | agosto 2028 | 30 giugno 2030 |
Chi corregge il PHP della distribuzione
Per circa tre anni dopo il rilascio le correzioni arrivano dal team di sicurezza di Debian, tramite il repository security.debian.org. Poi subentra Debian LTS, un progetto finanziato dalle aziende e svolto da sviluppatori Debian, che estende la manutenzione fino a cinque anni complessivi. Il PHP della distribuzione rientra di solito tra i pacchetti seguiti: per esempio, Debian LTS ha pubblicato aggiornamenti di php7.4 per Debian 11 fino ad agosto 2026, a pochi giorni dalla chiusura del supporto.
Dopo Debian LTS esiste Extended LTS, o ELTS, un servizio commerciale di Freexian che porta alcune release fino a dieci anni. La stessa wiki di Debian precisa che non è un progetto ufficiale e che i pacchetti coperti sono quelli scelti dalle organizzazioni abbonate. Prima di contare su ELTS per PHP, quindi, va verificato che il pacchetto rientri nel perimetro del servizio.
Il quadro a ottobre 2026 è questo. Debian 13 e Debian 12 ricevono ancora correzioni pubbliche per PHP 8.4 e 8.2. Su Debian 12 la manutenzione di Debian LTS prosegue fino a giugno 2028, oltre la fine del supporto di PHP 8.2 da parte del progetto, a dicembre 2026. Su Debian 11 e precedenti, chi usa il PHP della distribuzione senza un servizio commerciale non riceve più nulla.
deb.sury.org: cosa offre
Il repository di Ondřej Surý, che è anche tra i manutentori dei pacchetti PHP in Debian, fornisce molti rami di PHP installabili uno accanto all’altro: oggi vanno da 5.6 fino all’ultimo rilascio. È la ragione per cui è così diffuso: permette di far girare PHP 5.6 o 7.4 su una Debian recente, oppure un PHP più nuovo su una Debian più vecchia. Per Ubuntu esiste l’equivalente ppa:ondrej/php, di cui parliamo nell’articolo su PHP su Ubuntu LTS fuori supporto.
L’installazione su Debian usa il pacchetto con la chiave del repository e una riga in sources.list.d. Questi sono gli stessi passaggi dello script ufficiale pubblicato su packages.sury.org:
# Prerequisiti
sudo apt-get update
sudo apt-get -y install lsb-release ca-certificates curl
# Chiave del repository, distribuita come pacchetto
curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
sudo dpkg -i /tmp/debsuryorg-archive-keyring.deb
# Sorgente APT per la release in uso
echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" \
| sudo tee /etc/apt/sources.list.d/php.list
sudo apt-get updatedeb.sury.org: i limiti per il PHP legacy
Le FAQ del progetto sono chiare su alcuni punti che chi lavora con versioni vecchie deve conoscere:
- release supportate: sono supportate la stable, la oldstable e la release in Debian LTS. Debian 8, 9 e 10 non sono supportate, e i pacchetti delle release fuori supporto vengono rimossi poco dopo la scadenza, senza archivio delle versioni precedenti;
- rami fuori supporto: il repository fornisce correzioni di sicurezza anche per i rami di PHP in End of Life, ma «fino a un certo punto» e senza garanzia su quanto a lungo resteranno disponibili gratuitamente;
- librerie: oltre a PHP, il repository contiene versioni proprie di alcune librerie di sistema, come libgd o libpcre. Per questo le FAQ avvertono che, togliendo il repository, vanno reinstallati i pacchetti originali di Debian;
- offerta commerciale: per le release in End of Life esiste PHP LTS, un servizio a pagamento di Freexian realizzato insieme a Ondřej Surý.
C’è poi un effetto meno evidente. Su Debian 11, il pacchetto php7.4-fpm di deb.sury.org ha un numero di versione con epoch (1:7.4.33-…), mentre quello di Debian non ce l’ha (7.4.33-1+deb11u12). Per APT la versione con epoch è sempre più recente, quindi aggiungere il repository sostituisce il PHP 7.4 della distribuzione al primo apt upgrade, anche se nessuno lo ha chiesto esplicitamente. Da quel momento le correzioni del server dipendono da deb.sury.org e non più da Debian.
Pacchetti propri: quando servono
Restano i casi che nessuna delle due fonti copre: PHP 5.6 su Debian 9 o 10, PHP 7.4 su Debian 11 dopo la fine di Debian LTS, un ramo installato da deb.sury.org su una release ormai rimossa dal repository. In tutti questi casi i pacchetti installati sono fermi, e l’unico modo per correggerli senza cambiare ramo è ricostruirli con le patch.
Il lavoro parte dal pacchetto sorgente da cui deriva quello in uso, così da mantenere la stessa configurazione, le stesse estensioni e la stessa struttura dei file. Si aggiungono le correzioni delle vulnerabilità, adattate al codice del ramo, e si ricostruisce con gli strumenti standard di Debian. Lo schema, semplificato, è questo:
# Sorgente del pacchetto in uso e dipendenze di compilazione (servono le righe deb-src)
apt-get source php7.4
sudo apt-get build-dep php7.4
cd php7.4-7.4.33
# Le patch vanno in debian/patches e nell’elenco debian/patches/series.
# Nuova voce nel changelog con un suffisso locale: la versione diventa,
# per esempio, 7.4.33-1+deb11u12+pl1
dch --local +pl "Backport della correzione per CVE-AAAA-NNNNN"
# Compilazione dei pacchetti binari, senza firma
dpkg-buildpackage -us -uc -bIl passaggio difficile è in mezzo: adattare una correzione scritta per PHP 8.x al codice di un ramo vecchio, capire se la vulnerabilità esiste davvero in quel ramo e verificare che la patch non cambi il comportamento dell’applicazione. È il lavoro che facciamo con il backport delle patch, partendo dai pacchetti DEB in uso, della distribuzione o di deb.sury.org, e provandoli con l’applicazione reale prima del rilascio.
Un pacchetto proprio introduce anche una responsabilità. Se un giorno una delle due fonti pubblica una versione con un numero più alto, APT la installa al posto della tua. Serve quindi una regola di pinning APT che stabilisca da quale repository devono arrivare i pacchetti PHP.
Come scegliere la fonte
Non c’è una fonte migliore in assoluto. Alcune regole pratiche aiutano a decidere:
- se l’applicazione funziona con il PHP della release e la release è supportata, il repository di Debian è la scelta più semplice e più stabile;
- se serve un ramo diverso su una release supportata, deb.sury.org è una soluzione valida, a patto di seguire gli aggiornamenti e di sapere che le librerie di sistema cambiano;
- se la release o il ramo non sono più coperti da nessuno, servono pacchetti propri o un servizio commerciale, insieme a un piano di migrazione verso una release e un PHP supportati.
Cosa controllare su un server Debian
Per sapere su quale fonte stai contando bastano pochi comandi, da eseguire su ogni server:
# Release di Debian
cat /etc/debian_version
lsb_release -sc
# Repository configurati (file .list e .sources)
grep -rh -E '^(deb|URIs)' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
# Pacchetti PHP installati, con versione
dpkg -l 'php*' | grep '^ii'
# Da quale repository arriva il PHP-FPM in uso (sostituisci 7.4 con il tuo ramo)
apt-cache policy php7.4-fpm
# Ultime correzioni di sicurezza nel changelog
zcat /usr/share/doc/php7.4-fpm/changelog.Debian.gz | grep -m 10 -i cveUna versione con +debNNuN arriva da Debian, una con +0~ e +debianNN nel numero arriva di solito da deb.sury.org. Se apt-cache policy mostra solo /var/lib/dpkg/status come origine, il pacchetto non è più disponibile in nessun repository configurato e nessuno lo sta aggiornando.
Tirando le somme
Su Debian il PHP in produzione può arrivare dalla distribuzione, da deb.sury.org o da pacchetti propri, e ogni fonte smette di portare patch in modo diverso. Il PHP della distribuzione segue la release: a ottobre 2026 Debian 12 e 13 sono coperte, mentre per Debian 11 e precedenti resta solo l’ELTS commerciale, da verificare pacchetto per pacchetto. deb.sury.org offre molti rami affiancati sulle release supportate, rimuove quelle scadute e sostituisce anche alcune librerie di sistema. I pacchetti propri coprono i casi rimasti scoperti, ma richiedono competenze di backport e un pinning APT che li protegga. Il primo passo è sempre lo stesso: verificare con apt-cache policy da dove arriva il PHP che esegue il sito.
