PHP security updates are like malaria treatments

Applying PHP security updates is somewhat like taking a malaria treatment: they are, temporarily, worse than the disease itself. Let me explain.

Malaria is not a nice disease. I have had malaria a couple of times. We treated it with chloroquine (this was a few years ago). The treatment dose of chloroquine makes you feel worse than the malaria itself. But then you get better.

A PHP security hole is obviously a big issue for your average PHP site. I have had to apply patches to address these holes numerous times in the last few years. Unfortunately, it seems that each patch version for PHP introduces either new bugs or changes the published API. This causes all sorts of chaos and panic when the upgrade goes through, and lots of scrambling to fix a site that no longer works correctly. Sometimes you may not find the problem for several weeks in an infrequently used area of the site, so running a test server does not address this (besides, who wants to leave a known security hole online for several weeks?)

For example, PHP 5.2.7 was released to address a number of bugs and security holes but then was removed from distribution 3 days later because of an introduced bug changing the behaviour of magic quotes. That didn’t affect me because I did not use magic quotes… (Magic quotes were a majorly broken silly idea in the first place, but even worse is making it a configurable option so any code that I write has to test the setting… But let’s not get distracted.)

Or, to take an even more serious example, strtotime function return values changed in 5.1.0. As of 5.1.0, when strtotime is passed an invalid date, it returns FALSE instead of -1. This change was made without notice, and as far as I can tell, without any reference whatsoever in the huge changelog or even in bugs referenced in the changelog. That would have been better in the first place but this type of breaking change should never be made otherwise. I shouldn’t have to review all the changes to the PHP documentation, and then audit all 150,000+ lines of PHP code each time we update PHP!

That’s just two of the more obvious examples of the horrible PHP upgrade situation. Every time I have to upgrade, I just hold my breath and hope that no one has made any more silly breaking changes.

Leave a Reply

Your email address will not be published.