# PEAR archive: integrity and sunset suggestions

- Thread: https://externals.io/message/132881
- Original archive: https://news-web.php.net/php.internals/132881
- Started by Sebastian Bergmann on 2026-10-20T03:52:02+00:00
- Messages: 1
- RFC: End PEAR Project Endorsement (In voting) — https://externals.io/rfc/end_pear_endorsement.md
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #132881 — Sebastian Bergmann — 2026-10-20T03:52:02+00:00

URL: https://externals.io/message/132881#132881

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