Das PHP-Projekt beendet seine Unterstützung für PEAR, und ich halte das für richtig. Ein Ende mit Datum ist besser als ein Ende durch Verwahrlosung. Das statische Archiv, das pear.php.net ersetzen soll, wird go-pear.phar aber bis Ende 2027 unter derselben Adresse ausliefern, unter der 2019 eine Version mit Malware lag. Ob eine heruntergeladene Kopie die ist, die dort abgelegt wurde, lässt sich auch heute nicht prüfen. Ein eingefrorenes Archiv ist erst dann sicher, wenn sich seine Integrität prüfen lässt und seine letzten Nutzenden rechtzeitig merken, dass es endet.
Im Februar 2019 haben wir bei thePHP.cc einen Artikel mit dem Geständnis begonnen, dass wir nicht gedacht hatten, jemals wieder über PEAR zu schreiben. Diesmal war ich nicht überrascht. Offen war nur, wann das Thema zurückkommt. „Schatten der Vergangenheit“ endete mit einem Satz, auf den es jetzt eine Antwort gibt:
Wenn das PEAR-Projekt nicht genügend Arbeitskräfte hat, um einen sicheren Betrieb von pear.php.net und der dazugehörigen Infrastruktur sicherzustellen, dann sollte man dies vielleicht akzeptieren und darüber nachdenken, ob und wie man das PEAR-Projekt beenden kann.
Am 27. August 2026 hat Nick Sdot den RFC „End PEAR Project Endorsement“ zur Diskussion gestellt. Die Abstimmung endete gestern, am 19. Oktober 2026, um 13:15 Uhr UTC. Nötig war eine Mehrheit von zwei Dritteln. Der RFC erhielt 40 Ja-Stimmen, keine Nein-Stimme und keine Enthaltung.
Ein Wort zur Transparenz: Ich bin Mitglied des Boards der PHP Foundation und gehöre ihrem Ecosystem Security Team an. Der RFC ist kein Vorhaben der PHP Foundation. Ich habe am 5. Oktober 2026 mit Ja gestimmt.
Woher PEAR kommt und wie es so weit kam, hat Eric L. Barnes am 13. Oktober in „The History of PEAR, PHP's First Package Manager“ aufgeschrieben. Diese Geschichte erzähle ich hier nicht nach.
Die Diagnose von 2019 hat gehalten
Eine Aussage von 2019 hat das Jahr nicht überstanden. Wir schrieben, dass PHP eine PEAR-Umgebung mitinstalliert, solange beim Übersetzen nicht --without-pear angegeben wird. Am Tag, an dem unser Artikel erschien, schlug Nikita Popov auf internals vor, die Installation von PEAR in PHP 7.4 standardmäßig abzuschalten. Ich habe mit „+1“ geantwortet. Zehn Tage später war die Änderung committet. Seit PHP 7.4, erschienen am 28. November 2019, wird PEAR einschließlich PECL nur noch mit --with-pear installiert, und diese Option ist als veraltet markiert.
Nikita begründete seinen Vorschlag ausdrücklich nicht mit dem Einbruch:
It's not really the recent security breach itself, but rather the underlying issue that PEAR simply isn't actively maintained anymore.
Im März 2022 zeigte Thomas Chauchefoin von SonarSource, dass 2019 nicht nur ein einzelnes Artefakt das Problem gewesen war. Er fand in pearweb, der Software hinter pear.php.net, zwei Schwachstellen, die seit mehr als 15 Jahren ausnutzbar waren. Das Token zum Zurücksetzen eines Passworts ließ sich in weniger als 50 Versuchen erraten, und damit der Account jedes Maintainers übernehmen. Hochgeladene Pakete entpackte pearweb mit einer Version von Archive_Tar, die eine bekannte Schwachstelle hatte. Zusammen erlaubte das, beliebigen Code auf dem Server auszuführen. SonarSource meldete beides am 30. Juli 2021, behoben war es mit pearweb 1.32 am 13. März 2022. Die Zusammenfassung von SonarSource spricht von Fragen nach „the lack of security contributions from companies relying on them“.
Was der RFC über den Zustand von 2026 schreibt, liest sich wie die Fortsetzung. Die Website hat kaputte Links, eine Suche, die nicht funktioniert, und sichtbaren Spam, etwa Links zu Online-Casinos. Das Repository von pearweb wurde archiviert. Das PHP-Projekt hat keinen Zugriff auf Infrastruktur und Website von PEAR, obwohl beide unter php.net laufen. Laut den Metadaten von PEAR vom 22. Juni 2026 sind 534 der 603 Pakete als nicht mehr gepflegt markiert, und 63 der übrigen 69 wurden seit langer Zeit nicht aktualisiert.
Keine dieser Zahlen beschreibt das Versagen einer einzelnen Person. Sie beschreiben ein Projekt, das zu wenige Menschen hatte, um eine öffentliche Infrastruktur sicher zu betreiben. Das war 2019 unsere Diagnose, und sie hat sich bestätigt.
Der RFC beendet nur, wofür PHP verantwortlich ist
Der RFC schlägt vier Maßnahmen vor. Ein statisches Archiv mit Paketseiten, Downloads, Handbüchern und Bug Reports ersetzt pear.php.net. Es bleibt einschließlich der Endpunkte für den PEAR Installer bis zum 31. Dezember 2027 erreichbar und wird danach als Download angeboten. Ab PHP 8.7 wird der PEAR Installer nicht mehr mitgeliefert. Die offiziellen Websites nennen statt PEAR Composer als Paketmanager der Community, ohne dass Composer dadurch zu einem Projekt von PHP wird. Die Mailinglisten von PEAR wandern zu den „Inactive Lists“.
Der wichtigste Absatz des RFC steht in seiner Einleitung:
PHP internals cannot vote to stop independent maintainers from maintaining PEAR elsewhere. PHP internals can, however, decide what PHP bundles, what PHP domains serve, and what official websites endorse.
Das ist die Antwort auf das „ob und wie“ von 2019. Das PHP-Projekt beendet nicht PEAR, sondern seine eigene Verantwortung dafür. Wer PEAR als aktives Projekt fortführen will, kann das laut RFC weiterhin tun, unter einer eigenen Domain.
Frühere RFCs von Davey Shafik (2016) und James Titcumb (2025) kamen nie zur Abstimmung. Titcumb zog seinen noch am Tag der Veröffentlichung zurück, weil unklar geworden war, ob PHP überhaupt über PEAR bestimmen kann, und nannte das Thema „a can of worms“. Nick Sdot umgeht diese Frage, indem er Bundling, Hosting und Empfehlung voneinander trennt und nur über das abstimmen lässt, was ohnehin in der Hand des PHP-Projekts liegt.
Dazu kam Unterstützung von der anderen Seite. Chuck Burgess, langjähriger Maintainer von PEAR und Mitglied der PEAR Group, meldete sich während der Diskussion beim Autor des RFC und unterstützte das Vorhaben. Er hat auch selbst mit Ja gestimmt. Rowan Tommins fragte nach mehreren Kontaktversuchen und vielen Monaten ohne Ergebnis: „If that's not long enough, how long is?“
Wie wenig noch an PEAR hängt, rechnete Nick Sdot in derselben Diskussion vor. Von den sechs Paketen, die noch über PEAR veröffentlicht werden, gehören drei zur Infrastruktur von PEAR selbst, und zwei wurden kürzlich als nicht mehr gepflegt markiert. Übrig bleibt ein einziges unabhängiges Paket, Net_SMTP, und das gibt es auch auf Packagist.
Der letzte Grund für das Bundling ist weg
2019 schrieben wir, dass PHP PEAR nur noch deshalb standardmäßig installiert, weil pecl es braucht. Diesen Grund gibt es nicht mehr. Im September 2025 wurde James Titcumbs RFC „Recommend PIE and deprecate PECL“ mit 36 Ja-Stimmen, keiner Nein-Stimme und fünf Enthaltungen angenommen. Seitdem empfiehlt das PHP-Projekt PIE, den PHP Installer for Extensions. Version 1.0.0 erschien am 17. Juni 2025. PIE wird wie Composer als PHAR verteilt und findet Extensions über Packagist.
Im November 2020 hatte Derick Rethans als Release Manager von PHP 7.4 die Maintainer des php-Images, das Docker auf Docker Hub verteilt, noch gebeten, weiterhin mit --with-pear zu bauen, weil pecl der einzige offizielle Weg sei, Extensions zu installieren. Seit Juni 2026 werden die Images für PHP 8.6 ohne --with-pear gebaut. Die Images für PHP 8.2 bis 8.5 enthalten pecl weiterhin. Homebrew übersetzt PHP nach wie vor mit --with-pear.
In php-src liegt seit dem 10. Oktober 2025 der Pull Request #20124 von Jakub Zelenka, eröffnet einen Tag nach dem Rückzug von Titcumbs RFC zu PEAR. Der Entwurf entfernt PEAR und PECL gemeinsam: die Option --with-pear, das Verzeichnis pear/ und den Download von install-pear-nozlib.phar beim Erstellen der Quellarchive. Offen sind laut seiner Checkliste der Windows-Build, die Konstanten PEAR_INSTALL_DIR und PEAR_EXTENSION_DIR sowie eine Dokumentation, die auf PIE verweist. Der RFC legt die Richtung dieses Pull Requests für PHP 8.7 verbindlich fest.
Eingefroren ist nicht dasselbe wie sicher
Was das Archiv richtig macht, ergibt sich aus dem, was es nicht mehr hat. Ein statisches Archiv kennt keine Logins, kein Zurücksetzen von Passwörtern und keine Uploads, die auf dem Server entpackt werden. Beide Schwachstellen von 2022 steckten in Code, der auf dem Server lief, und diesen Code gibt es im Archiv nicht mehr. Die Angriffsfläche von 2022 verschwindet damit vollständig. In einem früheren Artikel habe ich geschrieben, dass die sicherste Tür die ist, die nie eingebaut wurde. Das Archiv baut gleich mehrere solcher Türen wieder aus.
Was bleibt, ist das Problem von 2019. Der Proof of Concept des Archivs liefert go-pear.phar und install-pear-nozlib.phar weiter aus. Beide Dateien sind Byte für Byte identisch mit denen, die heute auf pear.php.net liegen. Prüfsummen oder Signaturen gibt es nicht, weder im Proof of Concept noch im RFC noch in der Diskussion auf internals. Nick Sdot hat auf internals bestätigt, dass das Archiv diese Dateien weiter unter pear.php.net bereitstellen soll und die Domain sich nicht ändert. 2019 schrieben wir, dass die Maintainer von PEAR Signaturen hätten veröffentlichen sollen, damit sich go-pear.phar prüfen lässt. Dieses Argument gilt unverändert.
Eines ändert sich allerdings. Bisher konnte das PHP-Projekt darauf verweisen, dass es keinen Zugriff auf pear.php.net hat. Sobald das Archiv die heutige Website ersetzt, liefert das PHP-Projekt diese Dateien selbst aus. Damit liegt die Verantwortung für ihre Integrität bei ihm.
Dass diese Frage nicht nur alte Installationen betrifft, zeigt ein Pull Request von Daniel Scherzer. Das Skript scripts/dev/makedist, mit dem die Release Manager die Quellarchive von PHP erstellen, lädt install-pear-nozlib.phar bei jedem Release von pear.php.net herunter. Das gilt für alle Versionszweige von PHP 8.2 bis 8.6. Scherzer schreibt dazu, dass das „without any validation“ geschieht, und schlägt vor, die Datei stattdessen ins Repository von php-src aufzunehmen. Sein Versuch, sie aus den Quellen von PEAR neu zu bauen, ergab eine Datei mit einer anderen SHA-256-Prüfsumme, die sich nicht installieren ließ. Wer die heruntergeladene Datei gegen ihre Quellen prüfen will, kann das also derzeit nicht. Der Pull Request ist noch offen. PHP 8.5 erhält Sicherheitsupdates bis Ende 2029, PHP 8.6 noch länger. Ohne eine Änderung laden ihre Release Manager diese Datei noch Jahre nach dem 31. Dezember 2027 von einer Adresse, die es dann so nicht mehr geben soll.
Andrew Nesbitt, den Rowan Tommins in der Diskussion zitiert hat, beschreibt am Beispiel von CocoaPods, was das Einfrieren einer Registry bedeutet: „A frozen registry is the one place a package can never be patched again.“ Die Korrektur für eine Schwachstelle in einem PEAR-Paket gibt es bestenfalls noch auf Packagist. Für alle, die den PEAR Installer benutzen, bleibt die verwundbare Version die neueste.
Dann sind da die Zombies von 2019. Am 21. April 2014 habe ich angekündigt, dass PHPUnit nicht mehr als PEAR-Paket verteilt wird. PHPUnit 3.7.35 und 4.0.17, die letzten funktionierenden PEAR-Pakete, gaben bei jedem Aufruf des Test Runners einen Hinweis darauf aus. Am 1. Dezember 2014 folgten 3.7.36 und 4.0.18 als PEAR-Pakete, die kein funktionierendes PHPUnit mehr installierten, sondern nur ein Skript, das eine Fehlermeldung ausgab. Am 31. Dezember 2014 habe ich pear.phpunit.de abgeschaltet. Mehr als vier Jahre später kamen bei pear.phpunit.de noch immer jede Stunde Dutzende Anfragen von PEAR Installern an.
Ankündigung, Warnung und Grabstein haben diese Clients also nicht erreicht. Eine Warnung erreicht nur, wer die Ausgabe liest. Ein Cronjob oder ein vergessener Schritt in einem Build liest keine Ausgabe. Das Archiv hält solche Clients bis Ende 2027 stillschweigend am Leben. Am 1. Januar 2028 brechen sie ab, ohne dass vorher eine Warnung bei ihnen angekommen wäre.
Derick Rethans hat auf internals vorgeschlagen, das Archiv nur für eine begrenzte Zeit zu betreiben und danach einen Tarball auf museum.php.net abzulegen, „for archeologists“. Der RFC hat daraus die Frist bis Ende 2027 und den späteren Download gemacht. Auch für diesen Tarball stellt sich die Frage, woran sich prüfen lässt, dass er unverändert ist.
Die technischen Details entscheidet laut RFC das Infrastruktur-Team. Ich habe heute auf internals vier Vorschläge dafür gemacht:
- Ein signiertes Manifest mit den SHA-256-Prüfsummen aller Dateien im Archiv, veröffentlicht zusammen mit dem Archiv und später mit dem Tarball. Für
install-pear-nozlib.phargehört die Prüfsumme außerdem inmakedist, oder die Datei selbst ins Repository von php-src, wie Scherzer es vorschlägt. -
go-pear.pharals Grabstein: eine Datei, die keine PEAR-Umgebung mehr installiert, sondern nur erklärt, wie es mit Composer und PIE weitergeht. So habe ich es 2014 mit PHPUnit 3.7.36 und 4.0.18 gemacht. Fürinstall-pear-nozlib.phargeht das nicht, solange die Quellarchive von PHP diese Datei enthalten. - Brown-outs vor dem Stichtag, nach dem Vorbild von JCenter. JFrog hat Anfragen an JCenter 2024 erst stundenweise, dann einen ganzen Tag lang zu Maven Central umgeleitet, bevor die Umleitung dauerhaft wurde. So bekam laut Nesbitt jeder verbleibende Build einen Fehler, auf den er reagieren konnte, bevor der endgültige kam.
- Aggregierte Zugriffszahlen: welche Dateien und Endpunkte noch abgefragt werden, wie oft und von welchen Versionen des PEAR Installers. Ohne diese Zahlen weiß niemand, ob die letzten Nutzenden überhaupt noch erreichbar sind.
Jeder dieser Vorschläge kostet das Infrastruktur-Team Zeit, und fehlende Zeit hat PEAR erst dorthin gebracht, wo es heute steht. Brown-outs brechen Builds absichtlich. Ein Grabstein bricht Installationen, die heute noch funktionieren. Ich halte beides trotzdem für richtig, weil ein angekündigter Fehler billiger ist als der unangekündigte am 1. Januar 2028. Das Manifest mit Prüfsummen halte ich für das Minimum. Ohne es wiederholt das Archiv die Lücke von 2019, diesmal unter der Verantwortung des PHP-Projekts.
PEAR lebt im PHAR weiter
PHPUnit wurde von 2001 bis Juli 2006 auf pear.php.net veröffentlicht und danach bis Ende 2014 über meinen eigenen Kanal pear.phpunit.de, zusammen mit PHP_CodeCoverage, PHPUnit_MockObject, phpcpd und phploc. Auf pear.php.net habe ich außerdem Image_GraphViz und XML_Transformer betreut. Der PEAR Installer installierte Pakete global in ein Verzeichnis im include_path, also mussten alle Projekte auf einem Rechner dieselbe Version von PHPUnit benutzen. Composer installiert Abhängigkeiten pro Projekt, und von einem PHAR kann jedes Projekt seine eigene Version haben. Seit PHPUnit 3.7, erschienen im Herbst 2012, war der PEAR Installer nicht mehr der einzige Weg, PHPUnit zu installieren. Ab PHPUnit 4.0 war das PEAR-Paket nur noch eine Hülle um das PHAR.
Die Idee für das PHAR entstand im PEAR-Projekt. PHP_Archive, ein PEAR-Paket, das Davey Shafik ursprünglich entworfen hatte, erschien im Mai 2005 und machte es möglich, eine ganze PHP-Anwendung als eine Datei auszuliefern. Greg Beaver und Marcus Börger, die PHP_Archive gemeinsam mit Davey Shafik betreuten, haben darauf die Extension phar aufgebaut, die seit PHP 5.3 zu PHP gehört. PHPUnit wird heute als PHAR verteilt, ebenso Composer und PIE. Für PHPUnit gibt es GPG-Signaturen, für Composer SHA-256-Prüfsummen und für PIE Attestations, die sich mit gh attestation verify prüfen lassen. Auch go-pear.phar ist ein PHAR, nur gibt es dafür nichts davon.
Anderes von PEAR lebt weiter, ohne dass es noch jemand PEAR nennt: die Namenskonvention, aus der PSR-0 wurde, die Pakete unter pear/ auf Packagist und Werkzeuge wie PHP_CodeSniffer und phpDocumentor, die wie PHPUnit als PEAR-Pakete begannen. Barnes erzählt diese Linien ausführlich.
Mein Dank gilt allen, die PEAR getragen haben, als die meisten von uns längst weitergezogen waren. Chuck Burgess hat noch im September die verlorenen Bug-Seiten wiederhergestellt, damit das Archiv vollständig ist. 2019 schrieben wir, dass PEAR eine wesentliche treibende Kraft für die Professionalisierung von PHP war. Dabei bleibt es.
Vielleicht hängen deine Builds noch an PEAR
Bis zum 31. Dezember 2027 funktioniert alles weiter. Gerade deshalb fällt nichts auf. Drei Dinge solltest du vorher prüfen:
- Durchsuche Dockerfiles, CI-Konfigurationen und Provisionierungsskripte nach
go-pear,install-pear,pear install,pear channel-discoverundpecl install. Ein Dockerfile, das aufphp:8.6aufbaut undpecl installaufruft, schlägt fehl, denn diese Images enthaltenpeclnicht mehr. - Beziehe PEAR-Pakete, die du noch brauchst, mit Composer aus dem Vendor
pear/auf Packagist, und ersetzepecldurch PIE. Für Docker-Builds stellt PIE ein Image bereit, das sich während des Builds einbinden lässt, ohne im fertigen Image zu bleiben. - Finde die Systeme, von denen niemand mehr weiß. 2019 schrieben wir, dass viele Unternehmen nicht genau wissen, welche Anwendungen auf ihrer Infrastruktur noch laufen. Benutzt ein solches System PEAR, merkt das bis zum 1. Januar 2028 niemand.
Zum Prozess gehört auch das Ende
2019 haben wir Bruce Schneier zitiert: „Security ist ein Prozess, kein Produkt.“ Zu diesem Prozess gehört auch, etwas zu beenden. 2019 lautete die Frage, ob und wie sich PEAR beenden lässt. Jetzt ist nur noch offen, wie gut das gelingt. Im Januar 2019 konnte niemand prüfen, ob ein heruntergeladenes go-pear.phar das richtige war. Ob das im Dezember 2027 anders ist, hängt an einer Datei mit Prüfsummen.
Die wichtigsten Quellen für diesen Artikel sind der RFC „End PEAR Project Endorsement“ von Nick Sdot (Version 1.0.0), die Diskussion dazu auf internals, „The History of PEAR, PHP's First Package Manager“ von Eric L. Barnes (13. Oktober 2026) und „Sunsetting a Package Manager“ von Andrew Nesbitt (23. Juni 2026). Alle anderen Quellen sind im Text dort verlinkt, wo sie verwendet werden.
