Re: [PHP-DEV] Disable PEAR by default
On Tue, Feb 5, 2019, 9:09 PM Nikita Popov On Mon, Feb 4, 2019 at 1:32 PM Zeev Suraski 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 >
Re: [PHP-DEV] Disable PEAR by default
On Mon, Feb 4, 2019 at 1:32 PM Zeev Suraski wrote: > > > On Fri, Feb 1, 2019 at 1:27 PM Nikita Popov 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
Re: [PHP-DEV] Disable PEAR by default
On Fri, Feb 1, 2019 at 1:27 PM Nikita Popov 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
Re: [PHP-DEV] Disable PEAR by default
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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
On 02.02.2019 at 16:32, Lester Caine wrote: > On 02/02/2019 14:28, Peter Kokot wrote: > >> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
On 02/02/2019 14:28, Peter Kokot wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
> 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 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Disable PEAR by default
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 On 2/1/19 3:06 PM, Peter Kokot wrote: > Hello, > > On Fri, 1 Feb 2019 at 12:44, Joe Watkins wrote: >> >> +1 >> >> On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann 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
Re: [PHP-DEV] Disable PEAR by default
> 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
On 2/1/19 5:12 PM, Peter Kokot wrote: Hello, On Sat, 2 Feb 2019 at 02:08, Alice Wonder 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
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 wrote: +1 On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann 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." -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
Hello, On Sat, 2 Feb 2019 at 02:08, Alice Wonder 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
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 wrote: +1 On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann 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
Re: [PHP-DEV] Disable PEAR by default
On 1 February 2019 23:06:41 GMT+00:00, Peter Kokot 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
Hello, On Fri, 1 Feb 2019 at 12:44, Joe Watkins wrote: > > +1 > > On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Disable PEAR by default
+1 On Fri, 1 Feb 2019 at 12:35, Sebastian Bergmann 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Disable PEAR by default
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Disable PEAR by default
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
