Hi Nick, hi everyone,
voting on the "End PEAR Project Endorsement" RFC [1] closed yesterday.
While the results have not yet been officially announced on this list, I
want to offer a few suggestions for the static archive now, as the RFC
leaves its technical details to the infrastructure team.
First of all: thank you, Nick, for moving this forward, and thank you,
Chuck, for helping with the archive.
My suggestions all start from one observation: until 2027-12-31, the
archive will keep serving executable code from php.net. This includes
go-pear.phar, the file that was replaced with a malicious copy in January
2019.
1. Make the archive verifiable
Publish a manifest with the SHA-256 hash of every file the archive serves:
package tarballs, go-pear.phar, install-pear-nozlib.phar, and the REST
metadata. Sign it, and keep a copy in the archive's Git repository so that
it can be checked independently of the web server. The same manifest can
later accompany the download that replaces the browsable archive (Derick
suggested museum.php.net for that).
Static hosting removes the attack surface of pearweb itself: accounts,
password resets, uploads. On its own, it does not let anyone tell whether
a file has been tampered with.
2. Pin the installer that php-src downloads
When PHP is configured with --with-pear and install-pear-nozlib.phar is
not present in the source tree, pear/Makefile.frag [2] downloads it from
https://pear.php.net/install-pear-nozlib.phar and executes it without any
verification. I suggest checking the PHAR against a pinned SHA-256 hash in
all branches that still support --with-pear.
These branches also need a plan for 2028: PHP 8.6 will receive security
support well beyond 2027-12-31. Either install-pear-nozlib.phar stays
available until the last of these branches reaches its end of life, or the
download is changed in those branches.
3. Fail loudly and early, not silently and late
Forgotten automation is the main remaining user of the CLI endpoints. In
2019, for instance, nightly PHP builds on Travis CI broke because their
build script downloaded go-pear.phar. Two suggestions:
- Brown-outs in the months before the cut-off, as JFrog did when it
retired JCenter [3]: short, announced windows in which the CLI endpoints
and go-pear.phar return an error that points to an explanation, extended
step by step. The final shutdown then becomes a failure people have
already seen and recovered from. install-pear-nozlib.phar should be
excluded, see 2.
- After 2027-12-31, replace go-pear.phar with a tombstone PHAR that
explains what happened and where to go, and exits with a non-zero status,
instead of simply returning a 404. PHPUnit did this before pear.phpunit.de
was shut down: its final PEAR releases, 3.7.36 and 4.0.18, only printed an
error message.
4. Measure who is still out there
Aggregate request counts for the CLI endpoints, go-pear.phar, and
install-pear-nozlib.phar, per path and user agent and without IP
addresses, published from time to time, would tell us whether 2027-12-31
is the right date and whether the brown-outs reach anyone. Years after
pear.phpunit.de was shut down, PEAR clients were still sending dozens of
requests per hour to it.
Best regards,
Sebastian
[1] https://wiki.php.net/rfc/end_pear_endorsement
[2] https://github.com/php/php-src/blob/master/pear/Makefile.frag
[3] https://nesbitt.io/2026/06/23/sunsetting-a-package-manager.html
--
Sebastian Bergmann https://phpunit.expert
Stay up to date with PHPUnit: https://phpunit.expert/newsletter
