Just a reminder that PHP 5 is switching to security fixes *only*: time to upgrade to PHP 7!
secure.php.net/supported-versions.php
secure.php.netPosted Dec 30, 2016, 9:44 AM UTC
13169
secure.php.netYou mean, Php 5 won't be getting brand new bugs and just security updates? Guess it is a good time to stick to php 5...
23
We've only just completed the replacement of mysql_ with mysqli_ and I see we've also got the POSIX regex functions to do too before we can go to 7. Deep joy.
6
Congratulations on just noticing PHP moved to PCRE 12 years ago, and officially deprecated POSIX 7 years ago.
11
Oh we noticed, we just buried our head in the sand and hoped it would go away (deprecation does tend to last a long time so this is not a completely dumb strategy given that no application - not even ours - will last forever).
3
Here's a dangerous idea: write yourselves a compatibility layer that takes POSIX syntax and converts it to PCRE syntax, then keep your existing code as-is, and use PCRE only for new code. I think PCRE is mostly a proper superset of the semantics of POSIX, so this should be possible.
3
The key word there is 'mostly' - there's some nasty gotchas around promiscuous matching (see note 3 here) which have caught me out before when switching from one to the other.
Anyway I think we'll be going a search out and kill on all POSIX functions just like we did for mysql_
1
Replacing mysql_ is in most cases a simple search and replace. It was deprecated four years ago! What do you do with such long turn-around times?
The ereg functions are even more interesting. The manual have recommended preg since 2001 and ereg got deprecated in 2009.
5
We have an application with a large codebase which was first developed in the last millennium (in PHP 3 originally) which is still actively used by a number of paying customers.
I can understand mysql_ being dropped (although it was a ton of work replacing it with mysqli_ even with a lot of scripting to do the bulk of it) but I've never really been clear why there was perceived need to dump ereg. Do you know what the thinking was?
6
My last link says it was being removed in PHP 6 (lol). I seem to remember that PHP 6 was mostly designed by committee on a meetup (I was too young back then to keep track of the details). php6.se [in Swedish] says it was in 2005 and that they discussed dropping ereg because it allowed you to link against any regular expression lib, making the expressions themselves non-portable between PHP installations. This is kind of an unsatisfying reason to me. Perhaps it was also not maintained? I don't know.
3
Perhaps it was also not maintained?
Largely that. With PCRE being able to do everything the ereg functions could do (plus a lot more), there was no interest in maintaining two extensions to do the same thing, particularly since ereg depended on a quirky fork of a POSIX regex library from 1994.
There are a couple of more nuanced answers from 2009 on Internals that provide other reasons, too: Guilherme pointed out speed as another problem, and Rasmus called out its lack of Unicode support.
It's kind of remarkable ereg lasted as long as it did, honestly — there are discussions on Internals from 10 years ago where it was already taken as a given that it was being removed. It was on the chopping block initially for 5.3, would have been removed in 6.0, and was seriously considered for removal in 5.4 and 5.5 as well.
7
It can technically be done with search/replace and some minimal changes. If you're making the effort though, you might as well go all the way and upgrade to the OO interface and prepared statements.
0
Happy new year! My 2016 was not the best but having one more point to convince my clients to move to 7.1 is one lil good thing.
4
I would like to hear your argument for that.
You: Dear client, you need to pay me to upgrade our PHP installation to 7.1 because PHP 5.x won't receive any new features.
Client: I won't be getting new features?!
You: No no, these are programming language features, nothing that would be visible to you on the front end.
Client: So .... I need to pay you because..?
7
Client: So .... I need to pay you because..?
You: The ecosystem is moving to PHP 7. More and more libraries are requiring 7+, and this trend won't slow down. Also, when we move to PHP7, our projects automatically become twice faster and start taking less memory, which you'll feel immediately, and result in lower hardware costs going forward.
Client: Sounds good. What do we need to upgrade to 7?
You: Nothing, while we were talking, our test suite was running on 7 and it seems all tests pass. I'll go run a command on the production server and that's it.
16
Right, but OP's claim was that we should upgrade because PHP 5.6 is only getting security updates.
1
Well, it's time to start considering an upgrade, because that's the last step before EOL.
These things usually have to be planned. If you wait until EOL to start planning, then you'll be running your server on potentially insecure software for quite some time.
1
I almost cried
1
PHP 5.x hasn't been receiving new features for more than two years already. End of active support means it won't receive bug fixes anymore either. Of course, if your stable software already runs on 5.x without problems, then you probably don't need any bug fixes either.
9
[deleted]
0†
5.6 will receive security-related bug fixes.
3
Get a load of this guy. Why don't you make a post on internals about your sentiments? I'm sure it will be well received.
1
Well I mostly do backend work and fortunately the clients usually understand the language at least a little.
- For starters, 7.0/1 takes up less memory, so you can have more req/sec from the same resources.
- Type hints in arguments and return types, so we there are fewer tests to write.
I could convince some of them to upgrade just by the performance improvements. I don't really get paid to upgrade their servers. Just the fun with working with more modern language :)
4
Sure, there might be other, more convincing arguments, but PHP 5.6 only receiving security updates probably isn't one of them :-)
I don't really get paid to upgrade their servers.
Are you not compensated for your time?
4
I won't speak to your incompetence because you already did it.
1
?
1
PHP 5 will be around for quite a while. Security patches are really all that was left for it anyway.
4
And also bug fixes, which it will no longer have.
1
Tell that to Debian.
3
Debian will enter soft freeze next week. That means they block new packages in Stretch and focus on fixing bugs until they feel ready for release. Following the most common schedule we can expect Debian Stable to have PHP 7.0 in Q2 (not 7.1 unfortunately).
8
There are plenty of alternatives if you want a more bleeding edge version built on debian, so debian itself being a bit slower to adapt new major versions of applications is a feature, not a bug. For example ubuntu started shipping php7 as default from 16.04.
3
I administer a web site on a host which is still using 5.3.29, which is what I learned. Because this is the only site I administer, I have not made it a priority to update to compliance for newer versions. However it's something I have started working on recently.
Is there any kind of a tool I can use to check my pages to see if they are compliant, or the check for things which have been depreciate? At the same time are there things for PHP 7 which will not work with PHP 5.3.29?
3
You'll probably find the easiest possible thing to do is run up a quick VM running PHP7, deploy your code and see what happens.
6
Humor! I like it. Sometimes this board is just too serious. Wonder if airlines use your approach when upgrading?
-2
I found the php7cc tool quite helpful. If your app has an automated test suite, simple run it and you will see where needs changes.
For some sites I had, I went ahead and upgraded to php 7 (personal sites), but kept an eye on the error reports and I surely could see few minor problems that was easy to fix.
Most IDEs can emit warnings too, of you set the language to 7 or 7.1.
If you are using mysql_ extensions, note that 7 has it removed for good reasons. In the other way, php did get many syntax changes as well. Group use syntax, list syntax, short array, type hinting, etc they all are new to 5.3, so code written for 7 will break fatally in older versions.
2
I'm wondering if COBOL or RPG programmers have the same problem.
2
For the last 20 years I have maintained a C based program. Much of the code dates back to 1985. Been remarkably stable but it does seem like every 5 years or so we need to make adjustments as libraries and operating systems change. Painful. But at least we have gotten good at writing tests.
2
The version I'm stuck with on Production is not even in the calendar graph :)
2
I'm looking forward to maintain old PHP 4 projects after my vacation.
1
Just a reminder that PHP 7 has unpatched security flaws https://www.bleepingcomputer.com/news/security/unpatched-vulnerability-affecting-php-7-servers/
1
Python pickled objects, PHP's serialization, Java's serialization, etc... are stupid and dumb. They should not be used by anyone.
4
Why do you think they are dumb?
1
Because these features are so easy to misuse and responsible for so many security vulnerabilities I think that these kind of unsafe serialization libraries are a net negative.
1
You said they shouldn't be used by anyone. But there are circumstances when you need to serialize data in a performant way. These functions are faster than for example JSON because the format contains the metadata needed to allocate memory in large chunks. If well designed the format also could also be made so that elements are read in the right memory order. For a balanced search tree this could mean the difference between constantly rebalancing the tree or needing no balancing at all! (Not that PHP have a balanced search tree datastructure, but Python and Java has). At the extreme end one could argue for storing a raw memory dump but that would be even worse for security.
We prefer JSON as the first solution to serialization, but have also had the need for faster alternatives from time to time.
1
See https://www.reddit.com/r/PHP/comments/5kxkkt/3_critical_zeroday_flaws_found_in_php_7_%C3%A2_one/
Also, this was said right below here, in the other answers.
3
A lot of hosting providers are updating to PHP7 without BC to <5.6 and have most of client's sites broken.
1
[removed]
1
Welp, crap. But now I know how to explain why we need to drop PHP 5. YAY
0†
Nothing has changed, if you're still on PHP5 it's not because you want new features.
15
-6
I didn't bother reading this sensationalism, but I can assure you that unserialize() on PHP 5 is just as vulnerable as on PHP 7, even if some of the specific exploits differ. This also happens to be a very well known class of vulnerabilities that will likely never go away completely due to fundamental design issues in the format. If you are passing user-controlled values to unserialize() in 2016, you deserve whatever is headed your way.
15
Isn't php 5's unserialize() even more vulnerable with lack of a second $options argument to disable/filter classes?
1
If you are passing user-controlled values to unserialize() in 2016, you deserve whatever is headed your way.
If that's the case, why was "allowed_classes" added. This only makes sense if the content is untrusted.
1
It should not have been added and I voted against the addition. Other people disagreed ... :(
2
Feel your pain
1
BTW what makes the format inherently insecure to the point, as you say, "it'll never go away"?
Aside from the fact you're instantiating objects based on untrusted data.
1
If you are passing user-controlled values to unserialize() in 2016, you deserve whatever is headed your way.
If you are using Php in 2016, you deserve whatever is headed your way...
-19
What would you recommend as an alternative?
2
Use JSON. If serialize() is required, always use the allowed_classes whitelist.
3
Did you wanted us to see your global reddit karma?
1
See https://www.reddit.com/r/PHP/comments/5kxkkt/3_critical_zeroday_flaws_found_in_php_7_%C3%A2_one/
These issues involve unserialize(), which isn't to be applied to user input anyway.
5
So you're saying... PHP5 is still getting security fixes?
RH/CentOS/OEL 6.8 still have PHP 5.3 as the latest version in their repos and provide patches. CentOS 7 default PHP is 5.4! EOL for 6.8 is in 2020.
Of course you can add other repos or build from src but if you want to use the standard repos you are stuck with 5.3.3.
Redhat provides backport support for these packages. So patches applied in 5.6 can be ported back to 5.3 (if it is relevant).
Pretty neat because it means 5.6 will be supported until 2020 by redhat
But what about patches for 5.3 or 5.4 that aren't relevant for future versions? No one is actually looking for those anymore, which is why they're insecure. People seem to forget this when bringing up RH/Canonical/Debian LTS support.
No idea what they do but if it's not relevant then it's probably fine.
They also provide "Software Collections" which include newer versions of some things, with less of a guarantee on stability: https://developers.redhat.com/products/softwarecollections/overview/
Latest version of that includes php 5.6.
Yeah... until 31 Dec 2018. We've got lots of time.