Re: [RFC] Sunset PECL

On Mon, 9 Nov 2026, James Titcumb wrote: > On Sat, 7 Nov 2026, at 20:38, Derick Rethans wrote: > > > > If the long static state is considered a problem, we can just > > shorten it by a year, and shutting it down a year sooner. > > I'd actually be fine with this. as Rowan makes a good point about > long-time static unchanging deps. > > I'm wondering if that's actually already the case. I don't see a way > (at least with my permissions) to remove an existing release from PECL > in the instance it's deemed vulnerable. Maintainers can remove existing releases (it's hidden somewhere), and admins, like me, can remove any existing release. > If that's the case the biggest impact in that particular instance is > new releases that fix any vulnerabilities would only be available > through PIE. > > I would suggest two changes: > > - a mitigation contingency to this risk: if a serious vulnerability is > identified in a listed static package, we remove the affected > package version(s) manually. That would require hacking some XML and removing files, but it can be done. But as the period is only 6 months, then that is not a large problem. > > - reduce the overall timeline to 1yr, bring forward all the 2029 > dates to 2027. That's 6 months of "heads up", and 6 months of "read > only mode plus brownouts" before shutdown ad the end of 2027. Although I didn't say "to a year" but "by a year", I am still okay with your suggestion. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://xdebug.cloud Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social