In breve: compilare PHP significa scaricare il pacchetto sorgente ufficiale da php.net, stabilire con ./configure le interfacce e le estensioni desiderate, costruire con make, verificare con make test e poi installare. Ciò dà pieno controllo su versione e dotazione. Il prezzo: per ogni aggiornamento di sicurezza è responsabile Lei stesso, come da ultimo con PHP2Shell, quando si è dovuto ricostruire e riavviare tutti i processi.
Quando le build proprie di PHP hanno senso
La maggior parte dei server ottiene PHP da una fonte di pacchetti: dalla distribuzione Linux, da un repository di terze parti o tramite un'immagine container. Per l'esercizio normale è di solito la scelta migliore, perché le correzioni di sicurezza vengono fornite automaticamente.
Le build proprie hanno comunque il loro posto:
| Situazione | Fonte di pacchetti | Build propria |
|---|---|---|
| Normale server web | di solito meglio | raramente necessaria |
| Versione o opzione non presente in una fonte affidabile | non disponibile | sensata |
| Ricerca di errori su PHP stesso, build di debug | limitata | sensata |
| Dotazione funzionale minima per sistemi speciali | limitata | sensata |
| Aggiornamenti di sicurezza | arrivano con la fonte | compito proprio |
Chi sceglie le build proprie ha bisogno di un processo fisso per gli aggiornamenti, altrimenti il vantaggio diventa un rischio.
Requisiti
Secondo il manuale servono GNU make e un compilatore C; da PHP 8.4 il compilatore deve supportare C11. Chi costruisce dal repository Git invece che da un pacchetto di rilascio ha inoltre bisogno di autoconf (dalla 2.68), re2c (dalla 1.0.3 per PHP 8.3 e successive) e bison (dalla 3.0.0). Il README nel codice sorgente indica per Ubuntu questo punto di partenza:
sudo apt install -y pkg-config build-essential autoconf bison re2c libxml2-dev libsqlite3-dev
Per ogni estensione aggiuntiva si aggiungono i pacchetti di sviluppo corrispondenti, ad esempio per OpenSSL o libsodium.
Scaricare il codice sorgente e verificarne l'autenticità
Un PHP costruito in proprio è affidabile quanto il suo codice sorgente. php.net offre ogni pacchetto con checksum SHA-256 e firma GPG; le chiavi dei release manager si trovano nella pagina di download e nella pagina con le chiavi GPG.
curl -O https://www.php.net/distributions/php-8.4.27.tar.xz
curl -O https://www.php.net/distributions/php-8.4.27.tar.xz.asc
sha256sum php-8.4.27.tar.xz # confrontare con il valore su php.net
gpg --verify php-8.4.27.tar.xz.asc php-8.4.27.tar.xz
Si prosegue solo quando checksum e firma corrispondono.
Compilare PHP: configure, make, test
Il procedimento ha quattro passaggi:
- Configurare:
./configurecon le opzioni desiderate. Se si costruisce da Git, eseguire prima./buildconf. - Costruire:
make -j"$(nproc)"; il numero di job corrisponde, secondo il README, convenientemente al numero di core del processore. - Testare:
make TEST_PHP_ARGS=-j4 testesegue la suite di test di PHP. - Installare:
make install, a seconda della directory di destinazione con privilegi di root.
Un esempio di build PHP-FPM con directory di destinazione propria:
tar xf php-8.4.27.tar.xz && cd php-8.4.27
./configure --prefix=/opt/php-8.4 \
--with-config-file-path=/opt/php-8.4/etc \
--enable-fpm --with-fpm-user=www-data --with-fpm-group=www-data --with-fpm-systemd \
--with-openssl --with-sodium \
--disable-cgi
make -j"$(nproc)"
make TEST_PHP_ARGS=-j4 test
sudo make install
/opt/php-8.4/bin/php -v
Le opzioni più importanti in sintesi:
| Opzione | Effetto |
|---|---|
--enable-fpm |
costruisce PHP-FPM; con essa --with-fpm-user, --with-fpm-group, --with-fpm-systemd |
--with-config-file-path |
directory in cui PHP cerca il php.ini |
--with-openssl |
supporto OpenSSL; da PHP 7.4 il percorso viene trovato tramite pkg-config |
--with-sodium |
crittografia moderna con libsodium |
--disable-cgi |
rinuncia alla variante CGI, se non serve |
--enable-debug |
simboli di debug, secondo il README raccomandati per lo sviluppo, non per la produzione |
--enable-zts |
thread safety per le modalità di esecuzione con thread |
Con --prefix si possono installare più versioni costruite in proprio una accanto all'altra, ad esempio sotto /opt/php-8.3 e /opt/php-8.4. Ciò facilita i passaggi di versione, ma richiede disciplina: ogni versione installata è software a sé, che a ogni rilascio di sicurezza va ricostruito, anche se al momento nessun sito web la usa. Le build non più necessarie vanno rimosse completamente. Quali opzioni abbia una build esistente lo mostra php -i nella riga «Configure Command»; è il modello migliore per la ricostruzione successiva.
Avvertenza su OPcache: da PHP 8.5, secondo l'RFC approvato, OPcache è compilata stabilmente. Nelle versioni più vecchie viene costruita come estensione e caricata tramite zend_extension. Che cosa siano estensioni e interfacce lo spiegano Capire le estensioni PHP e SAPI spiegata.
Build proprie e sicurezza: gli obblighi dopo PHP2Shell
Il PHP compilato in proprio ha un reale vantaggio di sicurezza: si costruisce solo ciò che serve. Ogni estensione non costruita e ogni modalità di esecuzione non costruita è codice che non può contenere una vulnerabilità. Una build senza CGI, con poche estensioni e percorsi chiari è facile da tenere sotto controllo.
A ciò si contrappone un obbligo severo. Con PHP2Shell le distribuzioni hanno in parte consegnato i backport il 21/10/2026; chi costruisce da sé non riceve nulla in automatico. Concretamente significava:
- Scaricare e verificare il codice sorgente della versione corretta.
- Ricostruire con opzioni identiche;
php -imostra la riga configure originale. - Eseguire i test e installare.
- Riavviare tutti i processi PHP, come descritto in Riavviare PHP-FPM e tutti i worker.
- Verificare la versione in esecuzione, come spiegato in Verificare correttamente la versione di PHP e lo stato delle patch.
Un PHP costruito in proprio non compare in nessun gestore di pacchetti. Tenga un inventario di quali server eseguano build proprie in quale versione, altrimenti verranno trascurate alla prossima vulnerabilità.
Come aiuta concretamente PHP SOS?
Tramite il servizio di patch PHP supportiamo i gestori di build proprie:
- Rilevare l'esistente: troviamo le versioni PHP costruite in proprio e leggiamo le loro opzioni di build.
- Ricostruire: versione corretta con firma verificata, stesse opzioni e esecuzione completa dei test.
- Distribuire e riavviare: installazione, riavvio di tutti i processi, controllo della versione in esecuzione.
- Semplificare: dove una fonte di pacchetti mantenuta assolve lo stesso scopo, mostriamo il passaggio.
Domande frequenti
Quando conviene compilare PHP da sé?
Quando una versione o un'opzione necessaria non è disponibile in nessuna fonte di pacchetti affidabile, per lo sviluppo e la ricerca di errori su PHP stesso o per build molto snelle e speciali. Per i normali server web i pacchetti mantenuti sono di solito la scelta migliore.
Come verifico che il codice sorgente di PHP sia autentico?
php.net offre per ogni pacchetto sorgente un checksum SHA-256 e una firma GPG. Confronti il checksum e verifichi la firma con le chiavi dei release manager pubblicate su php.net.
Devo ricompilare dopo un rilascio di sicurezza?
Sì. Un PHP costruito in proprio non riceve aggiornamenti dalla distribuzione. Dopo PHP2Shell significava: costruire il codice sorgente di 8.5.12, 8.4.27, 8.3.36 o 8.2.35, installarlo e riavviare tutti i processi PHP.
Dove trovo tutte le opzioni di configure?
Con ./configure --help nella directory dei sorgenti. Il manuale indica le principali opzioni del core, le opzioni per le estensioni si trovano nelle relative pagine del manuale.