Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Disable PEAR by default »

Disable PEAR by default

php.internals

Nikita Popov

7 years ago
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

Sebastian Bergmann

7 years ago
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

Joe Watkins

7 years ago
+1 On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann <sebastian@php.net> wrote:

Peter Kokot

7 years ago
Hello, On Fri, 1 Feb 2019 at 12:44, Joe Watkins <krakjoe@gmail.com> wrote:
> > +1 > > On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann <sebastian@php.net> wrote: > > > 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
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

Rowan Collins

7 years ago
On 1 February 2019 23:06:41 GMT+00:00, Peter Kokot <peterkokot@gmail.com> wrote:
>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]

Alice Wonder

7 years ago
On 2/1/19 3:06 PM, Peter Kokot wrote:
> Hello, > > On Fri, 1 Feb 2019 at 12:44, Joe Watkins <krakjoe@gmail.com> wrote: >> >> +1 >> >> On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann <sebastian@php.net> wrote: >> >>> 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 > > 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.

Peter Kokot

7 years ago
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.
-- Peter Kokot

Alice Wonder

7 years ago
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?

Peter Kokot

7 years ago
> 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

Lester Caine

7 years ago
On 02/02/2019 02:10, Peter Kokot wrote:
>> 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...
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

Peter Kokot

7 years ago
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

Alice Wonder

7 years ago
On 2/1/19 5:08 PM, Alice Wonder wrote:
> On 2/1/19 3:06 PM, Peter Kokot wrote: >> Hello, >> >> On Fri, 1 Feb 2019 at 12:44, Joe Watkins <krakjoe@gmail.com> wrote: >>> >>> +1 >>> >>> On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann <sebastian@php.net> >>> wrote: >>> >>>> 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 >> >> 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. >
"because that is what composer provides." should be "because that is what composer specifies."

=?utf-8?B?5rGf5rmW5aSn6Jm+5LuB?=

7 years ago
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"<alice@librelamp.com>; Date: Sat, Feb 2, 2019 09:08 AM To: "internals"<internals@lists.php.net>; Subject: Re: [PHP-DEV] Disable PEAR by default On 2/1/19 3:06 PM, Peter Kokot wrote:
> Hello, > > On Fri, 1 Feb 2019 at 12:44, Joe Watkins <krakjoe@gmail.com> wrote: >> >> +1 >> >> On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann <sebastian@php.net> wrote: >> >>> 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 > > 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.
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Rowan Collins

7 years ago
On 02/02/2019 01:08, Alice Wonder wrote:
> 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]

Remi Collet

7 years ago
> 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

Nikita Popov

7 years ago
On Fri, Feb 1, 2019 at 12:27 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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

Zeev Suraski

7 years ago
On Fri, Feb 1, 2019 at 1:27 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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

Nikita Popov

7 years ago
On Mon, Feb 4, 2019 at 1:32 PM Zeev Suraski <zeev@php.net> wrote:
> > > On Fri, Feb 1, 2019 at 1:27 PM Nikita Popov <nikita.ppv@gmail.com> wrote: > >> 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 >
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

Pierre Joye

7 years ago
On Tue, Feb 5, 2019, 9:09 PM Nikita Popov <nikita.ppv@gmail.com wrote:
> On Mon, Feb 4, 2019 at 1:32 PM Zeev Suraski <zeev@php.net> wrote: > > 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

Nikita Popov

7 years ago
On Fri, Feb 1, 2019 at 12:27 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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