PHP uit de broncode compileren

Kort gezegd: PHP compileren betekent het officiële bronpakket van php.net downloaden, met ./configure de gewenste interfaces en extensies vastleggen, met make bouwen, met make test controleren en daarna installeren. Dat geeft volledige controle over versie en omvang. De prijs: voor elke beveiligingsupdate bent u zelf verantwoordelijk, zoals onlangs bij PHP2Shell, toen opnieuw moest worden gebouwd en alle processen opnieuw moesten worden gestart.

Wanneer eigen PHP-builds zinvol zijn

De meeste servers betrekken PHP uit een pakketbron: uit de Linux-distributie, een repository van een derde partij of via een containerimage. Dat is voor normaal bedrijf meestal de beste keuze, omdat beveiligingscorrecties automatisch worden nageleverd.

Eigen builds hebben toch hun plaats:

Wie voor eigen builds kiest, heeft een vast proces voor updates nodig, anders wordt het voordeel een risico.

Vereisten

Volgens de handleiding zijn GNU make en een C-compiler nodig; sinds PHP 8.4 moet de compiler C11 ondersteunen. Wie uit de Git-repository bouwt in plaats van uit een releasepakket, heeft bovendien autoconf (vanaf 2.68), re2c (vanaf 1.0.3 voor PHP 8.3 en nieuwer) en bison (vanaf 3.0.0) nodig. De README in de broncode noemt voor Ubuntu deze start:

sudo apt install -y pkg-config build-essential autoconf bison re2c libxml2-dev libsqlite3-dev

Voor elke extra extensie komen de passende ontwikkelpakketten erbij, bijvoorbeeld voor OpenSSL of libsodium.

Broncode laden en echtheid controleren

Een zelfgebouwd PHP is slechts zo betrouwbaar als zijn broncode. php.net biedt elk pakket aan met SHA-256-controlesom en GPG-handtekening; de sleutels van de release managers staan op de downloadpagina en de pagina met de GPG-sleutels.

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                     # vergelijken met de waarde op php.net
gpg --verify php-8.4.27.tar.xz.asc php-8.4.27.tar.xz

Pas als controlesom en handtekening kloppen, gaat het verder.

PHP compileren: configure, make, test

Het verloop heeft vier stappen:

1. Configureren: ./configure met de gewenste opties. Bij het bouwen uit Git eerst ./buildconf uitvoeren.
2. Bouwen: make -j"$(nproc)"; het aantal jobs komt volgens de README zinvol overeen met het aantal processorkernen.
3. Testen: make TEST_PHP_ARGS=-j4 test voert de testsuite van PHP uit.
4. Installeren: make install, afhankelijk van de doelmap met root-rechten.

Een voorbeeld voor een PHP-FPM-build met eigen doelmap:

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

De belangrijkste opties in een overzicht:

Met --prefix kunnen meerdere zelfgebouwde versies naast elkaar worden geïnstalleerd, bijvoorbeeld onder /opt/php-8.3 en /opt/php-8.4. Dat vergemakkelijkt omschakelingen, maar vraagt discipline: elke geïnstalleerde versie is eigen software die bij elke beveiligingsrelease opnieuw moet worden gebouwd, ook als er op dat moment geen website gebruik van maakt. Niet meer benodigde builds horen volledig te worden verwijderd. Welke opties een bestaande build heeft, toont php -i in de regel „Configure Command”; ze is het beste sjabloon voor de volgende nieuwbouw.

Aanwijzing over OPcache: sinds PHP 8.5 is OPcache volgens de aangenomen RFC vast ingecompileerd. Bij oudere versies wordt het als extensie gebouwd en via zend_extension geladen. Wat extensies en interfaces zijn, leggen PHP-extensies begrijpen en SAPI uitgelegd uit.

Eigen builds en beveiliging: de verplichtingen na PHP2Shell

Zelf gecompileerd PHP heeft een echt beveiligingsvoordeel: u bouwt alleen wat u nodig hebt. Elke niet gebouwde extensie en elke niet gebouwde bedrijfsmodus is code die geen lek kan bevatten. Een build zonder CGI, met weinig extensies en duidelijke paden is overzichtelijk.

Daar staat een harde verplichting tegenover. Distributies hebben bij PHP2Shell backports deels op 21 oktober 2026 geleverd; wie zelf bouwt, krijgt niets automatisch. Concreet betekende dat:

1. Broncode van de fix-versie laden en controleren.
2. Met identieke opties opnieuw bouwen; php -i toont de oorspronkelijke configure-regel.
3. Tests uitvoeren en installeren.
4. Alle PHP-processen opnieuw starten, zoals beschreven onder PHP-FPM en alle workers opnieuw starten.
5. De draaiende versie controleren, zoals uitgelegd onder PHP-versie en patchstatus goed controleren.

Hoe helpt PHP SOS concreet?

Via de PHP-patchservice ondersteunen wij beheerders van eigen builds:

• Bestand inventariseren: Wij vinden zelfgebouwde PHP-versies en lezen hun buildopties uit.
• Opnieuw bouwen: Fix-versie met gecontroleerde handtekening, dezelfde opties en volledige testrun.
• Uitrollen en herstarten: Installatie, herstart van alle processen, controle van de draaiende versie.
• Vereenvoudigen: Waar een onderhouden pakketbron hetzelfde doel dient, tonen wij de overstap.

Veelgestelde vragen

Bronnen

• PHP-handleiding: installatie uit de broncode
• PHP-handleiding: configure-opties
• PHP-handleiding: FPM installeren
• php.net: bronpakketten met controlesommen en handtekeningen