PHP version retirement

[Martin Waschbüsch]

Hi Dan,

> Am 16.08.2019 um 08:07 schrieb Dan Mahoney <danm at prime.gushi.org>:
> 
> Martin and others,
> 
> I don’t have a good answer for this, other than to say that PHP has been the bane of my existence for a while.  As a admin, I’ve lost more hours and sleep on PHP scripts than any other tool.  PHP is the programming language that brought us WordPress, MovableType, PHPNuke, PostNuke, PHPBB, and Drupal.  And I’ve had users running sites with all of them.  Shoddy security code and all.
> 
> The “best” way for running PHP (with the privileges of your webserver, as an apache module) was a security nightmare, and burned me badly.
> 
> PHP’s own builtin security “features” (for example, open_basedir or safe mode) fail to do what they want to do (and much canned code refuses to work with them turned on), while things like allow_url_fopen enabled by default have made even the simplest php-based homepage (where PHP is used as little more than a repacement for mod_include) vulnerable to reflection attacks.
> 
> Lots of php-based code also has had a horrible history of version upgrades.
> 
> Upgrading PHP burned me badly as well, as code would mysteriously break on shared hosting systems, and my users would complain about things breaking overnight, or errors being sent to stdout (i.e. the browser).  The PHP devs would randomly deprecate functions, which would break otherwise-working older code.
> 
> Let me give you one simple example: Gallery.  Gallery 1, which doesn’t require a database backend.  There’s no real good replacement I’ve found for it, but it’s coded in a hard to read/upgrade style.  I’ve secured it by disabling comments, as well as limiting access to the login/admin functions with additional .htaccess restrictions, as well as carefully monitoring the logs and file sizes.
> 
> The solution I ultimately arrived for keeping php both current *and* compatible was that using SuPHP, I can enable multiple versions of PHP to run concurrently, even back to php4, as well as limiting the permissions php scripts have down to the owner, so that each site/vhost has its own php.ini, users, and permissions.   I get here by building php’s CGI/CLI versions from scratch, and keeping copies of my ./configure arguments handy for each version, so I can easily rebuild them all if there’s a shared library change.  This also lets me easily swap in PHP versions to test if something will break, rather than replacing/upgrading the one ports installs.
> 
> Sent from my iPad

Thank you for your input.
While I agree that PHP, in general, has been and still is a source of lots of security issues, I do not think this is the central point in this debate.
There might be a high probability of security issues that are PHP related for all I know, but again, the real question is:

Why drop a package that has just had recent security updates after a couple of weeks?

I pointed out that I do not think lack of upstream development is in and of itself sufficient grounds for doing so. At the very least, while it may be unwise to use a now obsolete version of PHP, I doubt if an argument along the lines of 'We removed this from ports. It's for your own good' is a very good one. (For a number of reasons).

The only other arguments I got so far seem to be about resources. I can understand that. With limited resources you have to prioritize and something will have to give.
Now, in a reply to Adam, I asked specifically if there were pointers that would help me evaluate how much effort is really involved.
(My working theory being that I so far underestimate the work required to do this.)
Also, I asked if people were open to letting a group of people interested in doing so continue to maintain an old version of php so that it does not have to be removed from ports.
Kurt suggested that as a feasible way forward and I agree.
Earlier, Adam seemed open to discussing a way forward as well, but I am not sure that still is the case.
Since I do not yet feel comfortable that I correctly estimate the amount of work, if enough people can be found to volunteer for this, but I remain hopeful.

All this notwithstanding, would you be willing to exchange hints & ideas about securing (as far as possible) PHP setups some more, off-list?
I'd like to ask some more about your approach.

Best,

Martin