Re: Disable PEAR by default
| From: | Alice Wonder | 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: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?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.