8 thoughts on - Php 5.6 On CentOS 6

• Am 21.06.2020 um 20:30 schrieb H:

  PHP 5.6 is EOL. https://www.php.net/supported-versions.php

  Why would a project like SCL spend any efford on patching that old PHP
  release? Everyone using PHP is happy to get a current release. If your application insists on using 5.6 then move on and look for a different application.

  Alexander

• That was not helpful. I gave the rationale in my e-mail message.

• H,

  Remi has been working very nicely every time I needed to install a non-standard version. There is still a 5.6 version for CentOS 7 available.

  best regards
  –

• Thank you, I need it for CentOS 6 though. But, I have figured out another approach – moving it to the new server and doing the database upgrade and migration there. Since I already have php 7 on that machine, there should not be any problems.

• This my reply is not intended for the OP, as he stated he will not listen about End Of Life of of PHP 5. Just in case anybody comes across this thread, please read what is written on the page referred to by Alexander Dalloz:

  >> PHP 5.6 is EOL. https://www.php.net/supported-versions.php

  This in plain English language says that php 5 is not supported by vendor since Jan 1 2019, i.e. almost a year a a half now. This means that PHP development team does not release security patches, and even though RedHat “backports” patches to older versions, difference in internals between PHP version 5 and version 7 is quite significant, so you should not assume that even if RedHat team still backports security patches for issues discovered in version 7, you are safe: there may be still be issues in version 5 which by no means are discovered by anyone.

  This boils down to one thing. If you still have anything using PHP
  version 5.[any] you should migrate this to PHP version at least 7.2. You ideally should have done that before Jan. 1, 2019.

  I hope, this helps somebody.

  By no means I meant to question the brilliant job RedHat does backporting (taking my hat off and bowing to RedHat here). However, as I
  said, there may be bugs in PHP 5 that will not be relevant to PHP 7, hence there is nothing to backport to fix them.

  Valeri

• If you are using the packages PHP packages in CentOS and keep your OS up to date, you can disregard this.

  I realize you are out of touch with how CentOS packages (and RHEL packages they’re built from) are handled, since you’ve decided to stop using it and move to FreeBSD, but this is how Red Hat backports fixes to php and other enterprise software:

  https://access.redhat.com/security/updates/backporting

  So if someone is coming across this thread, know that if you are using the supported PHP packages in CentOS’s repositories, security fixes are backported, and if security issues are identified in the version in RHEL, they’ll issues fixes during the lifetime of the release. So, in CentOS 7, expect the php 5 packages to be supported for a couple more years, despite all the gnashing off teeth of the PHP upstream developers.

  If you plan on starting a new project, definitely start with php 7. But if you have concerns about an existing 5.x codebase, as long as you are keeping your OS up to date, you have some time to migrate.

  —
  Jonathan Billings

• Apparently, I didn’t manage to make myself clear enough, so you even think I have no idea about how RedHat backports fixes work. You gave the reference, when I read your first phrase, I was going to refer to a backporting page, but here you just gave that same URL:

  https://access.redhat.com/security/updates/backporting/

  Of course, my knowledge is not full and extremely precise, but I have decent idea of how it works, known it for years, and that was basis of my choice: CentOS, not a “rolling release” distribution like Debian. I
  will reiterate it in general, as I will attempt to base on it the case… but that will be later.

  1. RedHat chooses some version of some software [forget here the reason why that specific version], say, PHP 5.3, and does the best to keep that patched and secure for as long as they feel practical

  2. When PHP project moves on and stops updating 5.3, RedHat analyzes what new release fixes, ports these fixes back to version 5.3, analyzes patches PHP releases to new versions, and sees whether these patches are relevant to code in version 5.3, and ports fixes to 5.3 version.

  3. When PHP moves to higher version, say, 7 but still maintains version
  5, RedHat does the same as in 2. However, once version 5 is EOL, PHP
  project stops patching version 5. However, version 7 shares quite significant portion of code with version 5. So, once patch (or minor release fixing some things) of PHP 7 comes, RedHat again analyzes whether fixes are relevant to older version RedHat still maintains, it will most likely be version 5.6 now. Occasionally, with life cycle as long as 10 years, RedHat has to jump forward with minor version number skipping a few, it may be jump from 5.3 to 5.6, don’t catch me not citing exact version numbers.

  That is in general brilliant and rather effort consuming way RedHat manages to keep for quite long pretty much the same environment, thus allowing those who use it to not constantly adjust their code to ever moving, say, PHP, as opposed to Debian and clones, or BSD descendants
  (in whose cases PHP 5.6 EOL, you better have all ported to PHP 7 now). And we did not even mention that RedHat audits some code also, so things are even better.

  However, in this excellent picture there is one piece that is not covered. I know, the likelihood of what I will describe below in small, but it is not zero, not excluded.

  First: how weaknesses and bugs are discovered? Mostly by:

  A. User (I am including sysadmin running servers in such) discover something broken, not working as expected, and files bug report or PR
  (problem report is what some projects call it).

  B. Several big guys, like Amazon, Google, … have people auditing important for them parts of code, and file bug reports, and often even patches to fix it

  C. Several agencies sometimes do their auditing (CERT comes to my mind, someone may extend the list)

  If something is not discovered, no one will work on fixing it. But it still may represent danger, even though bad guys usually hunt after known stuff.

  Now, that PHP 5.6 EOL came year and a half ago, majority of “rolling”
  distributions (Debian and clones, FreeBSD, etc…) and people who use them switched over to version 7. Part of RedHat userbase did the same. As a consequence, PHP 5.6 has really slim userbase at this moment, so A.
  – user – is much less likely to find unknown problems. Big guys as in B. have decently powerful programmer teams, or enough money to hire someone who will rewrite code, so they most likely abandoned version 5.6
  practically. Agencies aimed purely at security as in C. are quite likely considering version 5.6 lowest priority.

  This should hopefully explain that PHP version 5.6, even patched by doing its best RedHat still may have undiscovered and not fixed bugs with security implications. One can argue, the probability of that is low. But there is no way to prove that there are none, the same as one can not prove an opposite.

  I hope, this is more clear than my original short comment.

  Valeri

  —
  ++++++++++++++++++++++++++++++++++++++++
  Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
  ++++++++++++++++++++++++++++++++++++++++

• Am 22.06.20 um 03:02 schrieb Valeri Galtsev:
  >

  AFAIK, RH proactively do eval and fuzzing on software packages and is an active reporter of security vulnerabilities to upstream projects.

  But what I wanted to say; with Appstreams in EL8 the life cycle changes drastically. AFAIK, everything outside of BaseOS repo does not have the 10 years support. PHP 73 support ends Nov 2021 in EL8
  but its supported by the PHP.NET until 6 Dec 2021. Albeit not a big difference but shows the changed game rules.