Joomla! Forum - community, help and support

Thanks again for the reply. The point I'm making is that Redhat/CentOS/Scientific Linux 6 (and probably 5 even) show evidence that they have successfully backported PHP. I would have to believe that they are using the $2y prefix too...

I found a test at: github.com/edas/password-compat/blob/master/version-test.php and tried a version of this on my CentOS machine:
and the result is: Pass. So it is capable of using the $2y prefix.

Couldn't this test be put into Joomla instead of checking the version number?

I don't know about Debian because I never use it. For Redhat/CentOS 6 systems it is apparent that it works correctly and it would be an easy fix for Joomla to include it. Just check for the .el6. substring in php_uname().

You said:

So that lands us with a pretty firm cutoff on PHP 5.3.7 or distros which have proper $2y support

I'm focusing on the second part and Redhat 6 and clones meet this requirement. It would be great all around (Joomla would benefit too by having a larger user-base) if Joomla could be run on these systems without hacks and additional repos. I've heard of the REMI repo but for other reasons I won't be able to install that on this system. I can hack the index.php code but I see it in at least four other places too and I don't want to have to hack multiple files every time there is an update to Joomla.

Thanks,

Steve

I ended up adding the SCL repo to get version 5.4.16 of PHP and configuring the Joomla Virtual Host to use that while all other Virtual Hosts using the default package. All seems ok.

steve-cousins wrote:Thanks again for the reply. The point I'm making is that Redhat/CentOS/Scientific Linux 6 (and probably 5 even) show evidence that they have successfully backported PHP. I would have to believe that they are using the $2y prefix too...

I found a test at: github.com/edas/password-compat/blob/master/version-test.php and tried a version of this on my CentOS machine:

Code: Select all

$hash = '$2y$04$usesomesillystringfore7hnbRJHxXVLeakoG8K30oukPsA.ztMG';
$test = crypt("password", $hash);
$pass = $test == $hash;

echo "Test for functionality of compat library: " . ($pass ? "Pass" : "Fail");

and the result is: Pass. So it is capable of using the $2y prefix.

Couldn't this test be put into Joomla instead of checking the version number?

I don't know about Debian because I never use it. For Redhat/CentOS 6 systems it is apparent that it works correctly and it would be an easy fix for Joomla to include it. Just check for the .el6. substring in php_uname().

You said:

So that lands us with a pretty firm cutoff on PHP 5.3.7 or distros which have proper $2y support

I'm focusing on the second part and Redhat 6 and clones meet this requirement. It would be great all around (Joomla would benefit too by having a larger user-base) if Joomla could be run on these systems without hacks and additional repos. I've heard of the REMI repo but for other reasons I won't be able to install that on this system. I can hack the index.php code but I see it in at least four other places too and I don't want to have to hack multiple files every time there is an update to Joomla.

Thanks,

Steve

Sorry to re-open an older thread but I've been contacted by a customer who's just hit across this (they're a little slack in applying updates but there you go).

There seems to be a pretty fundamental misunderstanding (on the part of the Joomla team and others) in this thread of how updates/packages work in RHEL/CentOS.

The base version is 5.3.3, with all security updates backported in. In other words, if there's a new feature added to (say) 5.3.4 it won't be present. However, if there's a security fix, it will be.

All the reasons given in this thread fall in the latter category. So whilst the official 5.3.3 may have been dead for a good number of years, the _vendor managed_ packages are still maintained and kept up to date with security fixes.

So, anyone running CentOS 6 or RHEL 6 is locked out of updating Joomla. To make it worse, the Joomla update component does not say "Oh, you cannot update from 3.2.x to 3.4.x because....". It simply shows the latest available update (3.2.7 in this case). How many of those users will be following closely enough to realise they've fallen behind?

In either case, using PHP version string checks is an awful way of doing things. As suggested above, functionality tests are a far,far saner way of doing things.

Using the SCL repo means going out of band, which itself poses potential risks down the line. Compiling from source on a production system with a package management system is an even worse solution as those installs easily get forgotten and remain updated.

Running a major distribution update just so that a CMS can continue working is not an acceptable option either, especially given the massive differences between CentOS 6 & 7.

Regarding RHEL, version 5 production support ends on march 31 2017, and extended life support on november 20 2020. Just using the production end lifetime, Joomla would have to support PHP 5.3, 5.4, 5.5, 5.6, and any releases on PHP 7 in the beginning of 2017. That would not be a very popular decision with Joomla developers.

As I've noted in this thread, we tried a feature detection implementation with the 3.2.0 release and it fell flat on its face. It created more errors than we could resolve in our code infrastructure and required us backing out a lot of the work that had been done because it was just too complex. With where we are at today, there are no viable options that can safely backport full support for the password hashing APIs to older versions of PHP, whether they are maintained by distros or not. I know this is an unpopular decision, but given our experiences in the BCrypt implementation, I do not see how we can adjust the software platform to work with these distro managed PHP versions in a feasible manner.

The one thing that I could think of is that a number of 3rd party developers who find this feature important create a separate "Joomla extra long support" distribution of one Joomla version, and support that for a number of years.

Tonie wrote:Regarding RHEL, version 5 production support ends on march 31 2017, and extended life support on november 20 2020. Just using the production end lifetime, Joomla would have to support PHP 5.3, 5.4, 5.5, 5.6, and any releases on PHP 7 in the beginning of 2017. That would not be a very popular decision with Joomla developers.

I don't disagree, but it's the users that need to use Joomla. Obviously there's a balance to be struck between users not being inconvenienced and devs not being inconvenienced (and so being driven away), so finding the right balance to strike might be challenging.

CentOS/RHEL 5 is now 2 majors behind, so I suppose a reasonable compromise is current (i.e. 7) + 1. I'd certainly argue that the extended support period shouldn't be factored in.

But It's not just 5 that's locked out by this change, CentOS 6/RHEL 6 are also essentially locked out.

It's not the forum to go in depth, but there may be very good reasons why someone is unwilling/unable to update to CentOS 7 at this point in time.

My customers have already pointed out to me that WP supports anything from 5.2.4 upwards. I know it's something of an apples & oranges comparison, but from their perspective I can understand why it seems more than a little odd. They'll probably come around to understanding it, but I think it's going to take quite a bit to stop them from being dubious about it.

mbabker wrote:As I've noted in this thread, we tried a feature detection implementation with the 3.2.0 release and it fell flat on its face. It created more errors than we could resolve in our code infrastructure and required us backing out a lot of the work that had been done because it was just too complex. With where we are at today, there are no viable options that can safely backport full support for the password hashing APIs to older versions of PHP, whether they are maintained by distros or not. I know this is an unpopular decision, but given our experiences in the BCrypt implementation, I do not see how we can adjust the software platform to work with these distro managed PHP versions in a feasible manner.

I think a good starting place would have been a warning in the backend (whether dismissable or not) rather than outright refusing to run. Manually disabling/nobbling the version check would be the equivalent, but will need repeating every time they update, so it's not the greatest solution. Whether or not things break after that, becomes the operators issue (so long as things fail sanely).

What the current change has succeeded in doing is encouraging users to implement some potentially hacky workaround to get it working.

Taking the SCL method as an example. It's a RH supported repo, so should be safe - except of course that if you want to use it (without making 5.4 the primary version of PHP) you need to bring mod_cgi into the mix. So now your exposure to vulnerabilities is Joomla + PHP + mod_cgi + base stack.

I don't pretend to know the exact answer, and I appreciate you're trying to keep code complexity down, but given that RH holds an estimated 65% of the server market, it's not a good distro to have locked out.



The bit I'm really struggling with though, is the effect the change has on confidence in the future supportability of Joomla. Can we expect to see a similar dramatic change in the future?

It's one thing to find a way around it this time, but if it's suddenly decided to require (for example) 5.5 as a minimum in (for example) 18 months time, then at that point you're again looking at abandoning a supported mainstream distribution for the sake of a single CMS (I chose 5.5 because CentOS/RHEL 7 is 5.4 so would again be blocked).

Although I disagree with the decision, what it really boils down to is customers start getting unhappy when they have to pay for things like a major OS upgrade before it's even close to officially being needed. The customer in this case has already floated the idea of a migration to a different CMS in the medium to long-term, and I'm having problems finding fault with some of their concerns.

They chose a long-term support distribution for good reason, and though they'll likely swallow the cost this time round, they're eyeing the exits. Ideally, I'd like to avoid that, but an argument that they should move onto a less stable distro just isn't going to win

Tonie wrote:The one thing that I could think of is that a number of 3rd party developers who find this feature important create a separate "Joomla extra long support" distribution of one Joomla version, and support that for a number of years.

The thing is, supporting current versions of distributions shouldn't be considered a 'feature'. The codebase on RHEL 6 isn't out-of-date, though the feature set may well be.

Not to mention, RHEL 7 (PHP 5.4) was released 10 June 2014. The changes we're talking about were rolled out in Joomla 3.3 - 30 Apr 2014. So the at the time of the change, CentOS/RHEL 6 (PHP 5.3.3) was the latest version available.

Again, that gives rise to concerns of what happens when 7 is a bit older, will it suddenly be locked out of future Joomla updates because the goalpost has moved again?