On 05/11/2026 20:34, James Titcumb wrote:
I'd like to introduce an RFC to lay out a timeline to sunset PECL and
open it for discussion.
RFC text is at https://wiki.php.net/rfc/sunset_pecl
Hi James,
Thanks for moving this forward. I have a slight concern with the long
gap between going fully read-only (mid-2027) and retiring the repository
(end of 2029).
In one of the PEAR threads, I linked this blog post by Andrew Nesbitt
where he points out the risk of freezing a package which turns out to
contain a vulnerability:
https://nesbitt.io/2026/06/23/sunsetting-a-package-manager.html In the
current environment, two and a half years seems a long time to serve
something nobody can patch.
I think there are two ways we could lessen that risk:
1) Have a longer interim stage, where functionality is limited, and
deprecation clearly flagged, before going fully read-only.
For instance, registration of new packages could be disabled, and
perhaps restrictions placed on version numbers - e.g. allow Swoole
6.1.13 and 6.2.6 as patching existing series, but force 6.3.0 to be PIE
only.
We could also restrict packages from listing compatibility with new PHP
versions - there's probably no reason for anyone to use PECL to install
anything on PHP 8.7 / 9.0.
2) Establish a process up front for package maintainers to request
publication of security releases, with only a small number of users
granted write access.
As Andrew points out, if it's suitably restricted, this security process
doesn't need to use the same automation as the original system, it just
needs a way for trusted user to manually upload the releases.
What do you think?
--
Rowan Tommins
[IMSoP]
