Mantenere l'infrastruttura di build di PHP per Windows: strumenti per build e aggiornamenti di sicurezza

La maggior parte degli sviluppatori PHP non pensa mai a come viene compilato PHP. Lo scaricano, lo installano con un comando o con un'immagine precompilata e iniziano a lavorare. Ed è esattamente così che dovrebbe essere. Un sistema di build sta facendo il suo lavoro quando il risultato finale appare ottimo e funziona come previsto.

Dietro ogni rilascio ufficiale di PHP per Windows c'è molta infrastruttura: compilatori, SDK, librerie di dipendenze, compatibilità delle estensioni, pipeline CI e aggiornamenti di sicurezza che mantengono funzionanti le versioni PHP supportate.

Nell'ambito del mio lavoro per The PHP Foundation, l'attenzione si è concentrata sul lato Windows di PHP: mantenere e migliorare l'infrastruttura di build, aggiornare le dipendenze, supportare le build delle estensioni e rendere il processo più affidabile per le release PHP attuali e future.

Questo post è uno sguardo a quel lavoro, al perché è importante e a cosa comporta mantenere PHP in salute su Windows.

Perché il supporto a Windows conta ancora

PHP è ampiamente utilizzato su Linux, dato che il caso d'uso più comune è l'esecuzione di applicazioni web, ma il supporto a Windows resta importante per diverse ragioni.

Molti sviluppatori usano Windows come ambiente di sviluppo locale, e molte aziende eseguono applicazioni PHP su server Windows. Numerosi utenti ne dipendono per ambienti di test locali, strumenti CLI ed estensioni che devono funzionare in modo affidabile su Windows. Secondo il sondaggio annuale sugli sviluppatori di Stack Overflow del 2025 quasi il 50% degli intervistati usa Windows per lo sviluppo.

Le build ufficiali di PHP per Windows sono importanti perché forniscono una base di riferimento affidabile e fanno parte del processo di rilascio del progetto PHP.

Ciò significa che il supporto a Windows non riguarda solo la produzione della build finale di PHP. Riguarda il mantenimento dell'intera catena che rende possibile un runtime PHP affidabile.

Il sistema di build è ora una toolchain

Compilare PHP su Windows è molto diverso dal compilarlo su sistemi Unix-like.

Su Linux e macOS, compilare PHP di solito dipende da package manager per le dipendenze e da toolchain di build popolari e facili da usare. Su Windows, PHP utilizza un sistema di build separato costruito attorno a MSVC, Windows SDK che gestisce varie versioni di MSVC, script di build personalizzati e dipendenze precompilate personalizzate con patch specifiche per PHP.

Una build di PHP per Windows deve sapere:

• Quale toolset di Visual Studio usare
• Quale Windows SDK targetizzare
• Quali pacchetti di dipendenze sono disponibili
• Quali versioni delle librerie sono compatibili con ciascun branch di PHP
• Se una build è x64, x86, thread-safe, non-thread-safe, debug o release

Una parte importante del mio lavoro è stata consolidare tutto questo in una toolchain moderna: php/php-windows-builder.

Build delle estensioni PHP per Windows

Abbiamo iniziato con lo scopo di rendere più semplice compilare estensioni PHP su Windows. L'obiettivo era dare agli autori di estensioni un percorso per produrre build compatibili con la nuova direzione di PIE. Ma poiché questo nuovo modo di distribuire le estensioni di PHP tramite PIE è ancora in evoluzione, abbiamo anche ripristinato le build Windows per i rilasci delle estensioni su PECL. Nell'ambito di questo lavoro, abbiamo pubblicato build per più di 100 estensioni attivamente mantenute.

Questo è importante perché le build delle estensioni per Windows sono state storicamente problematiche per i maintainer. Gli autori di estensioni spesso non hanno l'ambiente di build Windows completo in locale, e molti contributori hanno più familiarità con i flussi di lavoro basati su Linux. Un builder con un'interfaccia unificata e input noti offre all'ecosistema un punto comune dove testare, fare debug e migliorare le build Windows.

- name: Build the extension
  uses: php/php-windows-builder/extension@v1
  with:
    extension-url: https://github.com/xdebug/xdebug
    extension-ref: '3.5.3'
    php-version: '8.5'
    ts: nts
    arch: x64
    args: --with-xdebug
    libs: zlib

Non si tratta solo di comodità. Cambia ciò che è possibile fare. Per la maggior parte delle estensioni, compilare per Windows è facile quanto copiare uno dei workflow di esempio che abbiamo.

Automatizzare le build di release per Windows

Oltre a migliorare il supporto per la compilazione delle estensioni PHP, abbiamo anche migliorato il modo in cui il runtime PHP viene compilato e mantenuto su Windows. Ora disponiamo di workflow automatizzati in php/php-windows-builder che compilano PHP sui nuovi tag in php/php-src, eseguono i test, le distribuiscono al server dei download e le rendono disponibili sul sito PHP. Si tratta di un enorme miglioramento rispetto a quello che era un processo manuale con ritardi, in cui le build venivano eseguite manualmente da una sola persona nel team Windows e testate dopo la pubblicazione.

Aggiornamenti delle dipendenze e testing

Nell'ambito dei miglioramenti all'infrastruttura di build di PHP, abbiamo anche creato un workflow di test bench. Ci permette di compilare PHP con build non pubblicate delle dipendenze PHP direttamente dagli artefatti dei workflow GitHub, invece di recuperarle dai server PHP. Questo ci consente di testare gli aggiornamenti delle dipendenze.

Prima che esistesse questa infrastruttura di test bench, alcuni aggiornamenti delle dipendenze venivano ritardati o evitati perché testarli adeguatamente su Windows era troppo lento, troppo manuale o troppo complesso. Con un builder e un test bench dedicati, gli aggiornamenti delle dipendenze possono essere testati più rapidamente su branch e configurazioni di PHP. Questo ci aiuta a muoverci più velocemente sia sul fronte della compatibilità sia su quello della sicurezza.

PHP 8.0 fino a PHP 8.3 usano il toolset di Visual Studio 2019, mentre le versioni più recenti come PHP 8.4 e PHP 8.5 usano il toolset di Visual Studio 2022. PHP 8.6 userà il toolset di Visual Studio 2026. Queste transizioni sembrano semplici, ma in pratica influenzano flag del compilatore, build delle dipendenze, compatibilità delle estensioni, immagini base della CI e decisioni di supporto a lungo termine.

Mantenere tutto questo funzionante significa testare costantemente combinazioni di branch PHP, versioni di Visual Studio e pacchetti di dipendenze. php/php-windows-builder ci offre un modo strutturato per farlo, invece di affidarci a build manuali una tantum.

Il lavoro sulla sicurezza: CVE, aggiornamenti delle dipendenze e fix backportati

Una gran parte del mantenimento di PHP per Windows è lavoro sulla sicurezza.

Spesso questo significa aggiornare le librerie di dipendenze su cui si basano PHP e le sue estensioni quando ricevono fix per CVE o quando nuove funzionalità lo richiedono. Tra queste ci sono librerie come libcurl, OpenSSL, ICU, SQLite, libxml2, libjpeg e oltre 40 altre.

Quando una di queste librerie corregge una vulnerabilità, lo stack di dipendenze Windows deve essere rivisto, ricompilato e testato. Il lavoro non è semplice come incrementare un numero di versione.

Una nuova release di una dipendenza può cambiare il comportamento dell'ABI, rimuovere API, richiedere la ricompilazione di un'altra dipendenza, esporre nuovi avvisi del compilatore o rompere un'estensione che prima si compilava senza problemi.

Ad esempio, aggiornare OpenSSL richiede di ricompilare curl e altre librerie che dipendono da essa. Aggiornare ICU può introdurre avvisi MSVC o modifiche a livello di header che influenzano l'estensione intl. Aggiornare Apache deve essere valutato con attenzione perché il modulo Apache di PHP deve rimanere compatibile con il più ampio ecosistema Windows, inclusi gli utenti che eseguono installer di terze parti privi di maintainer, ma che hanno comunque una vasta base di utenti.

C'è anche il lavoro di backporting. A volte il percorso più sicuro per un branch PHP supportato non è far avanzare l'intero stack di dipendenze, ma applicare o adattare patch di sicurezza mirate. Questo significa rivedere i fix upstream, verificare se si applicano correttamente alla versione usata da PHP per Windows, ricompilare la libreria interessata e validare che la build corretta rimanga compatibile con PHP e le sue estensioni.

Questo equilibrio è importante. Vogliamo che gli utenti ricevano rapidamente i fix di sicurezza, ma dobbiamo anche evitare di introdurre regressioni nelle release PHP supportate. La manutenzione della sicurezza su Windows è quindi un processo attento di monitoraggio delle CVE, revisione delle modifiche upstream, ricompilazione delle dipendenze, backport dei fix dove appropriato e validazione del risultato tramite le suite di test di PHP e build reali delle estensioni.

Questa è una delle parti meno visibili del lavoro, ma anche una delle più importanti. Un runtime PHP sicuro dipende non solo dal codice sorgente di PHP, ma anche dalle librerie native che vengono distribuite con esso.

Nell'ambito di questo processo, abbiamo aggiornato queste dipendenze affrontando una serie di problemi di sicurezza segnalati per esse nell'ultimo anno.

Abbiamo anche aggiornato queste dipendenze a release più recenti per correzioni di bug e nuove funzionalità.

La CI è diventata essenziale

Il lavoro moderno su PHP per Windows dipende fortemente dalla CI.

Non basta compilare PHP una volta in locale e rilasciarlo. Serve un testing ripetibile su branch, architetture, versioni delle dipendenze e combinazioni di runtime.

Nell'ambito di php/php-windows-builder, ora abbiamo un approccio basato su GitHub Actions per compilare PHP e le sue estensioni; si tratta di un miglioramento rispetto ai primi giorni in cui queste venivano compilate sulla macchina Windows fornita da Microsoft.

Prepararsi al futuro

Il supporto a Windows deve anche guardare avanti.

Un'area importante è il supporto alle architetture. Storicamente, PHP per Windows ha distribuito build x86 e x64. Ma il valore del supporto a x86 continua a diminuire, dato che i sistemi Windows moderni sono in stragrande maggioranza a 64 bit, mentre l'interesse per ARM64 è in crescita.

Questo crea un'importante domanda a lungo termine: come dovrebbe apparire in futuro la matrice ufficiale delle build Windows di PHP?

Abbandonare x86 e investire in ARM64 potrebbe avere più senso per le versioni future. Ma questo tipo di decisione non può essere presa alla leggera. Richiede di capire chi dipende ancora da x86, quale compatibilità viene effettivamente preservata e quali nuovi utenti trarrebbero beneficio dalle build ARM64.

Parte del lavoro consiste nel rendere possibili queste transizioni prima che diventino urgenti.

In conclusione

La manutenzione dell'open source è invisibile per design. Se tutto va bene, gli utenti non notano che una dipendenza è stata ricompilata, che un problema del compilatore è stato risolto, che un'estensione è stata corretta o che un workflow CI è stato migliorato. Scaricano semplicemente PHP e continuano a lavorare.

Questo è l'obiettivo.

Ma è anche il motivo per cui vale la pena parlare ogni tanto di questo lavoro. L'affidabilità di un progetto come PHP dipende da molti livelli di manutenzione che avvengono lontano dai riflettori.

Il lato Windows di PHP ha il proprio insieme di sfide, e continuare a investire in esso aiuta a mantenere PHP accessibile a più sviluppatori, più ambienti e più casi d'uso.