Re: [Astlinux-devel] PHP 5.6 EoL

[Lonnie A. <li...@lo...>]

> On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote:
> 
> Hi Devs
>  
> Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year?
> I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better.

Hi Michael,

Indeed, this is a can-of-worms.

1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year.  Rinse and repeat.

https://www.php.net/supported-versions.php

Our current 5.6 version was the closest to LTS they have offered.  Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases.

BTW, each new PHP release is not 100% backward compatible.


2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data.  This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat.

Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger
https://bugs.php.net/bug.php?id=69652

We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used.  This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data.

It appears later PHP versions use the same timezonedb.h file, though some details may have changed.


3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least.


4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin.


That is a summary for the can-of-worms.

Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure.

BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL.
--
m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014
--

At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump.

As always, open to comments.

Lonnie