Re: Disable PEAR by default

From: Date: Sat, 02 Feb 2019 01:18:04 +0000
Subject: Re: Disable PEAR by default
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-104008@lists.php.net to get a copy of this message
On 2/1/19 5:12 PM, Peter Kokot wrote:
Hello, On Sat, 2 Feb 2019 at 02:08, Alice Wonder <alice@librelamp.com> wrote:
I do not like composer. A problem I have encountered, a project specifies a version for a dependency. That version has vulnerability, developer fixed it in newer release, but composer keeps pulling in the older version because that is what composer provides. And it can be the dependency of a dependency of a dependency. I do not like Composer. Adding a "recognition page" while cutting PEAR off also seems, well, slimy.
Frankly, this is irrelevant. If you don't use Composer, that's your choice. PEAR isn't maintained and will cause similar issues all the time. Not removing this installation option from php-src in the near future means maintaining patches for all that time this option will be present in the PHP and shipping separate pear package for all Linux distributions. I don't like the sound of that.
Many PEAR packages are maintained, and they are globally installed meaning when a vulnerability is found, there is one to be fixed and everything on the system is fixed. Composer is like static linking compared to PEAR which is liked shared linking. Yes it's my opinion, it just seems that deprecating it is a reactionary decision caused by the current unfortunate situation, but there's no reason why Composer will not also have the same issue as the current situation. All it takes is hijacking a github account and trojan updates are easy to push through composer. So what problem is this really solving?

« previous php.internals (#104008) next »