Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] End PEAR Project Endorsement »

[RFC] End PEAR Project Endorsement

php.internals

Nick

5 days ago
Hey internals, I would like to open the discussion to "End PEAR Project Endorsement": https://wiki.php.net/rfc/end_pear_endorsement Over the last months the state of PEAR was several times discussed here. Multiple people reached out to PEAR via direct and official channels; no finite solution could be found. About three months ago I started going through all previous discussions and old (not voted) RFC attempts; I don't see an unsolvable blocker. Hence, I drafted this RFC, and created a static mirror of the PEAR website (to keep the CLI working; infra team was consulted). After that, it once again was tried to find a cooperative solution (foundation also aware), and things given time to play out another two months -- with no finite result. PEAR was a great effort, and we can all be grateful to the people who invested their time to make it happen. However, times changed -- people use Composer. The PEAR site is partly broken, spammed, has very little activity, and as of recent happens to be unmaintained. We win nothing by further stalling a decision; I believe we should stop the endorsement for PEAR. This RFC attempts to address all open questions from previous discussions, and seeks to offer a balanced and practical solution. --- Cheers Nick

Rowan Tommins [IMSoP]

5 days ago
Hi Nick, On 27 August 2026 04:36:50 BST, Nick Sdot <php@nicksdot.dev> wrote:
>Hey internals, > >I would like to open the discussion to "End PEAR Project Endorsement": >https://wiki.php.net/rfc/end_pear_endorsement
Thanks for putting this together and moving the conversation forward. I wholeheartedly support this course of action.
>We win nothing by further stalling a decision; I believe we should stop the endorsement for PEAR.
I think this is the key: a lot of the comments on previous discussions were about "giving a chance" for one or other individual or group to revive the website. Multiple attempted contacts were made, and many months have gone by, with nobody reporting a positive result. If that's not long enough, how long is? If the site stays alive in its current state for 10 years, it will continue to be exploited by spammers and probably worse. That's not in anyone's interest. - Coincidentally, Andrew Nesbitt, who writes tooling and analysis comparing different packaging systems, wrote a recent post about approaches to sunsetting: <https://nesbitt.io/2026/06/23/sunsetting-a-package-manager.html> One of the points he discusses is that freezing a channel rather than taking it offline means that security vulnerabilities are also frozen in place, with no way to supersede them for anyone still using the old tooling. I think readonly is probably the right approach in this case at least in the short term, but actively sunsetting later is maybe something to consider. - My only other specific comment is that looking at the draft mirror, only some of the bug reports seem to be there. I'm guessing this is because of the problem Juliette reported a while ago that many of them have started showing an error about unconfirmed email addresses. I wonder if being logged in as a package maintainer would be enough to see them, or if they're gone for good unless someone with admin access appears. Does anyone have an account to check? Thanks again - and thanks also to everyone who has contributed to PEAR in the past, and everyone who has tried to reach someone to bring it back to life. Regards, Rowan Tommins [IMSoP]

Nick

5 days ago
Thanks Rowan, On 27.08.26 20:17, Rowan Tommins [IMSoP] wrote:
> One of the points he discusses is that freezing a channel rather than taking it offline means that security vulnerabilities are also frozen in place, with no way to supersede them for anyone still using the old tooling. > > I think readonly is probably the right approach in this case at least in the short term, but actively sunsetting later is maybe something to consider. >
Agreed. The infra team also would prefer sunsetting at some point; it's in the future scope of the RFC. Also, it's mentioned in the RFC but probably worth to be highlighted here: only 6 packages are still publishing to PEAR. - 3/6 are PEAR infra packages - 2/6 are non-PEAR infra packages (but by a PEAR Group member) were recently marked as unmaintained Which makes it exactly one single independent package that is still maintained (legend!): Net_SMTP (which is also on Packagist). I think we can safely say that security is not a very pressing concern in this very situation; and that keeping the CLI alive for a while is to demonstrate good manners rather than serving high demand. :)
> My only other specific comment is that looking at the draft mirror, only some of the bug reports seem to be there. I'm guessing this is because of the problem Juliette reported a while ago that many of them have started showing an error about unconfirmed email addresses. > > I wonder if being logged in as a package maintainer would be enough to see them, or if they're gone for good unless someone with admin access appears. Does anyone have an account to check?
Correct. Only bugs that are accessible on the PEAR website are in the archive. Rather than archiving and linking error pages with no relevant content, I omitted those. Saves resources and clicks. Some of the pages could be recovered from year 2007 snapshots on archive.org, but that's quite some extra work. Since the PEAR site itself no longer has those pages, it’s probably: A) reasonable to expect anyone who wants to look up such old bugs to visit archive.org themselves B) not the job of the archive to me more complete than its source; hence, out of scope for the RFC That said, if an admin would provide a database dump I am keen to backfill missing bugs at any time (before or after the archive goes online).
-- Cheers Nick