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
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
+1
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
Hello,
+1
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
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]
Hello,
+1
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.
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
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.
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?
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
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
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
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
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.
To my knowledge, the official php.net Windows binaries do not contain
support for PECL/PEAR, anyway.
--
Christoph M. Becker
Hello,
+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."
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
Hello,
+1
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.
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]
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
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/3781I 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
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
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/3781This 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
- 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
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
I would go with a warning in 7.4 and remove entirely in 8.
best,
Pierre