# Disable PEAR by default - Thread: https://externals.io/message/103977 - Original archive: https://news-web.php.net/php.internals/103977 - Started by Nikita Popov on 2019-02-01T11:27:28+00:00 - Messages: 22 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #103977 — Nikita Popov — 2019-02-01T11:27:28+00:00 URL: https://externals.io/message/103977#103977 Hi internals, I would like to suggest that installation of PEAR is disabled by default in PHP 7.4. PR: https://github.com/php/php-src/pull/3781 I think the reasons for this should be obvious. It's not really the recent security breach itself, but rather the underlying issue that PEAR simply isn't actively maintained anymore. Currently PEAR is broken on master due to the removal of each(), which was deprecated in PHP 7.2. Apparently, since that time nobody noticed that PEAR is throwing deprecation errors, or at least nobody bothered to fix them. (I've submitted https://github.com/pear/Console_Getopt/pull/3 to fix at least this particular issue.) It's somewhat unfortunate that PEAR and PECL are coupled projects, but I don't think that should prevent us from changing this default. Regards, Nikita --- ## #103978 — Sebastian Bergmann — 2019-02-01T11:35:26+00:00 URL: https://externals.io/message/103977#103978 · In reply to: #103977 Am 01.02.2019 um 12:27 schrieb Nikita Popov: > I would like to suggest that installation of PEAR is disabled by default in > PHP 7.4. PR: https://github.com/php/php-src/pull/3781 +1 --- ## #103980 — Joe Watkins — 2019-02-01T11:44:33+00:00 URL: https://externals.io/message/103977#103980 · In reply to: #103978 +1 > Am 01.02.2019 um 12:27 schrieb Nikita Popov: > > […] > in > > […] > > +1 --- ## #104002 — Peter Kokot — 2019-02-01T23:06:41+00:00 URL: https://externals.io/message/103977#104002 · In reply to: #103980 Hello, > > +1 > > > > > […] Thank you Nikita for the pull request for this. With all the respect to PEAR project and people behind it, maybe the PEAR itself should be added to some sort of recognition page in the manual for their involvement and work on the first installer of PHP code and initial move into code reuse, open source PHP libraries, and all that. As time went forward, Composer took over the role of such installer in PHP community. One of the most problematic issues and a reason for the following questions is that I haven't noticed there has been any major involvement in the past few years or some roadmap created for PEAR (I'm not talking about PEAR packages here, only the PEAR core script). Code itself is legacy and needs almost a complete rewrite. Omitting things like PSR-4 makes coding with it very legacy, that's why it is not recommended anymore. Why is PEAR even part of the php-src? From my understanding, that is because of only one element/script. That is pecl script. For everything else it can be downloaded separately, as is Composer and all other tools needed for the usual daily workflow with PHP. So, Q1: Shouldn't be a much better approach here to deprecate this installation option in PHP 7.4 and remove it completely in PHP 8? Q2: Follow up question, what to do with PECL scrip then? Is in PHP even possible to start a new project such as a pecl command line tool that would offer a replacement for current pecl script? With only disabling installation option, nothing major is done actually, I think but if there is some other plan here that +1 I guess. -- Peter Kokot --- ## #104003 — Rowan Collins — 2019-02-01T23:58:32+00:00 URL: https://externals.io/message/103977#104003 · In reply to: #104002 >Q2: Follow up question, what to do with PECL scrip then? Is in PHP >even possible to start a new project such as a pecl command line tool >that would offer a replacement for current pecl script? It's certainly possible, and was the aim of Pickle: https://github.com/FriendsOfPHP/pickle As far as I know, the effort stalled only for lack of human resources to get it stable, not because of any fundamental blockers, so if someone took it in, it could probably happen. Regards, -- Rowan Collins [IMSoP] --- ## #104004 — Alice Wonder — 2019-02-02T01:08:19+00:00 URL: https://externals.io/message/103977#104004 · In reply to: #104002 > Hello, > > > > […] > > Thank you Nikita for the pull request for this. With all the respect > to PEAR project and people behind it, maybe the PEAR itself should be > added to some sort of recognition page in the manual for their > involvement and work on the first installer of PHP code and initial > move into code reuse, open source PHP libraries, and all that. As time > went forward, Composer took over the role of such installer in PHP > community. 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. --- ## #104006 — Peter Kokot — 2019-02-02T01:12:26+00:00 URL: https://externals.io/message/103977#104006 · In reply to: #104004 Hello, > 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. -- Peter Kokot --- ## #104007 — Alice Wonder — 2019-02-02T01:12:44+00:00 URL: https://externals.io/message/103977#104007 · In reply to: #104004 > > > […] > > 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. > "because that is what composer provides." should be "because that is what composer specifies." --- ## #104008 — Alice Wonder — 2019-02-02T01:18:04+00:00 URL: https://externals.io/message/103977#104008 · In reply to: #104006 > Hello, > > > > […] > > 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? --- ## #104010 — Peter Kokot — 2019-02-02T02:10:47+00:00 URL: https://externals.io/message/103977#104010 · In reply to: #104008 > 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. Which is great. Practice showed that global PHP packages are not that good actually and managing dependencies on a local level (per project) is much more scalable and overall better, but whatever works for your project. > Composer is like static linking compared to PEAR which is liked shared > linking. Composer can install things globally. I'm not sure I understand why is this even a discussion Composer vs. PEAR core installer script at the moment. The pull request is about disabling the PEAR option. Which I suggest to go further because, for example, waiting for a PHP 10 release for this step is really not a smart move for multitude of reasons... > So what problem is this really solving? Every PEAR issue actually that was caused in the several years. This time it was the each(), next version will be foo()... Not to mention that still there are bugs out there that are really painful to solve. For example, shared core (shipped) PHP extensions and PEAR is a no go without a patch. I mean if there are maintainers, and people who want to keep this PEAR in the php-src repository, fine I guess. But then I'm not sure what can be done here anyway... -- Peter Kokot --- ## #104012 — me@jhdxr.com — 2019-02-02T07:37:43+00:00 URL: https://externals.io/message/103977#104012 · In reply to: #104004 It's ok that you don't like Composer. You can find or even create a new tool which fit you needs. The reason we are talking about PEAR here, is it's bundled in the core, and no one is maintaining it. We are not saying Composer should be included into the core, at least not this thread. ------------------ Original ------------------ From: "Alice Wonder"; Date: Sat, Feb 2, 2019 09:08 AM To: "internals"; Subject: Re: [PHP-DEV] Disable PEAR by default > Hello, > > > > […] > > Thank you Nikita for the pull request for this. With all the respect > to PEAR project and people behind it, maybe the PEAR itself should be > added to some sort of recognition page in the manual for their > involvement and work on the first installer of PHP code and initial > move into code reuse, open source PHP libraries, and all that. As time > went forward, Composer took over the role of such installer in PHP > community. 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. --- ## #104013 — Remi Collet — 2019-02-02T08:02:32+00:00 URL: https://externals.io/message/103977#104013 · In reply to: #104002 > Composer took over the role of such installer in PHP community. But sadly "composer" is NOT an installer. (it is a Dependency Manager for PHP) Ex: not having "role" for files is a nightmare, and make necessary to use terrible workaround (such as using .gitattributes), and thus making PHP dev the butt of other language dev jokes... Remi --- ## #104016 — Nikita Popov — 2019-02-02T09:14:48+00:00 URL: https://externals.io/message/103977#104016 · In reply to: #103977 > Hi internals, > > I would like to suggest that installation of PEAR is disabled by default > in PHP 7.4. PR: https://github.com/php/php-src/pull/3781 > > I think the reasons for this should be obvious. It's not really the recent > security breach itself, but rather the underlying issue that PEAR simply > isn't actively maintained anymore. > > Currently PEAR is broken on master due to the removal of each(), which was > deprecated in PHP 7.2. Apparently, since that time nobody noticed that PEAR > is throwing deprecation errors, or at least nobody bothered to fix them. > (I've submitted https://github.com/pear/Console_Getopt/pull/3 to fix at > least this particular issue.) > > It's somewhat unfortunate that PEAR and PECL are coupled projects, but I > don't think that should prevent us from changing this default. > > Regards, > Nikita > To reiterate what Peter has said: This is not about whether you personally like PEAR or Composer. There is no suggestion here to replace PEAR with Composer in our distribution. We simply shouldn't be making an endorsement either way. I understand that distros are having a hard time dealing with the fact that pretty much all modern package management (in PHP and elsewhere) has moved towards per-project rather than global dependencies. However, complaining about that on this thread is not going to bring PEAR back to popularity. We have to deal with the situation as it is, not as we would like it to be. Nikita --- ## #104017 — Lester Caine — 2019-02-02T09:27:02+00:00 URL: https://externals.io/message/103977#104017 · In reply to: #104010 > > […] > Composer can install things globally. I'm not sure I understand why is > this even a discussion Composer vs. PEAR core installer script at the > moment. The pull request is about disabling the PEAR option. Which I > suggest to go further because, for example, waiting for a PHP 10 > release for this step is really not a smart move for multitude of > reasons... Previously Composer has been pushed as the alternative to using PEAR to maintain third party add-ons. If you disable PEAR then there needs to be an alternative way to provide similar functionality. The NICE thing about PEAR is that it can be managed either by pulling the global packages as in the case of say Horde or one can bundle the same packages locally while maintaining local tailoring of those packages. That you don't understand why they are being linked is perhaps part of the whole problem? Legacy projects CAN at least pull copies of the key third party PEAR packages without the problem of someone else messing them up. Yes the likes of each() screwing things up is a problem and is all part of the agro introduced by deprecating code that is currently working safely and securely, but it is a lot easier to patch that in a PEAR based system than in composer based ones until official patches filter through. Simply trying to rebuild systems heavily reliant on one to work with the other is yet another drain on limited resources. -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk --- ## #104024 — Peter Kokot — 2019-02-02T14:28:25+00:00 URL: https://externals.io/message/103977#104024 · In reply to: #104017 Hello, I understand we won't be able to reach common understanding about PEAR. But anyway, first of all, thanks for all the answers and informational feedback. I'd just like to remind everyone one thing. We're now on a good way to reach another 7+ years [1] of keeping PEAR in the PHP core with all the maintenance that it should include. Disabling an installation option for *nix environments doesn't mean deprecation and removal from the PHP core. It will still ship with Linux distro packages, and all the PHP stacks as long as it is available, with some even longer as a standalone package. Even PHP releases themselves will still include downloaded PEAR [2]. And most of all, let's not forget that it can also be installed separately as a standalone software and maybe there will be even PEAR 2.0 one day (very little chances of that happening but hey). About PECL, then I assume we keep it as is for this period also. Unclear, required to install PEAR to be able to run the pecl command, and optionally moving this part elsewhere out of the PHP. Specially, to package maintainers (Linux distros), another repository/project out of the scope of the PHP internals etc. [1] Approximate timeline simulation where BC breaks are allowed: PHP 10.0.0 2031 PHP 9.0.0 2026 PHP 8.0.0 2020-2021 PHP 7.0.0 2015-12-03 PHP 5.0.0 2004-07-13 PHP 4.0.0 2000-05-22 [2] https://github.com/php/php-src/blob/master/makedist#L118 -- Peter Kokot --- ## #104025 — Lester Caine — 2019-02-02T15:32:30+00:00 URL: https://externals.io/message/103977#104025 · In reply to: #104024 > About PECL, then I assume we keep it as is for this period also. > Unclear, required to install PEAR to be able to run the pecl command, > and optionally moving this part elsewhere out of the PHP. Specially, > to package maintainers (Linux distros), another repository/project out > of the scope of the PHP internals etc. I have to admit that since nowadays I only install PHP via OpenSUSE, what is in core is not actually relevant to me directly since even the packages that HAVE been dropped from core are still fully supported! BUT many of the people I am supporting are only using Windows so it is nice that there is a tidy path for 'package management'. That has included adding PECL packages in recent years and which was still working nicely. Those people have not upgraded from PHP5 for many reasons and having to address additional changes to a stable windows base is just more blockers to bringing the over 70% of sites that are still on PHP5 forward to PHP7. Especially if other moves make Windows a second class citizen? -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk --- ## #104029 — Christoph M. Becker — 2019-02-02T16:36:05+00:00 URL: https://externals.io/message/103977#104029 · In reply to: #104025 > > > > […] > > I have to admit that since nowadays I only install PHP via OpenSUSE, > what is in core is not actually relevant to me directly since even the > packages that HAVE been dropped from core are still fully supported! BUT > many of the people I am supporting are only using Windows so it is nice > that there is a tidy path for 'package management'. That has included > adding PECL packages in recent years and which was still working nicely. > Those people have not upgraded from PHP5 for many reasons and having to > address additional changes to a stable windows base is just more > blockers to bringing the over 70% of sites that are still on PHP5 > forward to PHP7. To my knowledge, the official php.net Windows binaries do not contain support for PECL/PEAR, anyway. -- Christoph M. Becker --- ## #104034 — Rowan Collins — 2019-02-02T17:59:57+00:00 URL: https://externals.io/message/103977#104034 · In reply to: #104004 > That version has vulnerability, developer fixed it in newer release, > but composer keeps pulling in the older version because that is what > composer provides. Have you seen https://packagist.phpcomposer.com/packages/roave/security-advisories ? It's a very simple composer package which lists packages with known vulnerabilities as incompatible, so that composer will skip them even if it means downgrading to meet the constraints of other packages you've requested. I'm not sure what other solution any package manager could provide, other than allowing you to install any version you liked, even if the authors stated that they were incompatible. Regards, -- Rowan Collins [IMSoP] --- ## #104117 — Zeev Suraski — 2019-02-04T12:32:19+00:00 URL: https://externals.io/message/103977#104117 · In reply to: #103977 > Hi internals, > > I would like to suggest that installation of PEAR is disabled by default in > PHP 7.4. PR: https://github.com/php/php-src/pull/3781 This thread went a bit off topic, but to return to its original subject - I'm also supportive of this move. Zeev --- ## #104184 — Nikita Popov — 2019-02-05T14:08:51+00:00 URL: https://externals.io/message/103977#104184 · In reply to: #104117 > > > > > > […] > > > This thread went a bit off topic, but to return to its original subject - > I'm also supportive of this move. > > Zeev > I think the main question we need to decide if we might want to go a step further and not just disable PEAR by default, but rather remove the option from configure entirely. Either right away in PHP-7.4 or in master for PHP 8. It's always easy to manually install PEAR via go-pear.phar (well, apart from right now because pear.php.net is down -- but then again the --enable-pear option is also broken now). Given that PHP 7.4 already comes with lots of ./configure changes due to the migration to pkg-config, which will require people to adjust their configure lines anyway, this might be a good moment to drop the PEAR flag altogether. Nikita --- ## #104185 — Pierre Joye — 2019-02-05T14:21:13+00:00 URL: https://externals.io/message/103977#104185 · In reply to: #104184 > > > I think the main question we need to decide if we might want to go a step > further and not just disable PEAR by default, but rather remove the option > from configure entirely. Either right away in PHP-7.4 or in master for PHP > 8. I would go with a warning in 7.4 and remove entirely in 8. best, Pierre --- ## #104338 — Nikita Popov — 2019-02-11T10:16:13+00:00 URL: https://externals.io/message/103977#104338 > Hi internals, > > I would like to suggest that installation of PEAR is disabled by default > in PHP 7.4. PR: https://github.com/php/php-src/pull/3781 > > I think the reasons for this should be obvious. It's not really the recent > security breach itself, but rather the underlying issue that PEAR simply > isn't actively maintained anymore. > > Currently PEAR is broken on master due to the removal of each(), which was > deprecated in PHP 7.2. Apparently, since that time nobody noticed that PEAR > is throwing deprecation errors, or at least nobody bothered to fix them. > (I've submitted https://github.com/pear/Console_Getopt/pull/3 to fix at > least this particular issue.) > > It's somewhat unfortunate that PEAR and PECL are coupled projects, but I > don't think that should prevent us from changing this default. > > Regards, > Nikita > I've gone ahead and merged this change. PEAR is no longer installed by default, instead --with-pear must be specified. Additionally the option generates a deprecation warning during ./configure now. Nikita