RE: PHP versioning and security information
> I have backported unstable's php 4.2.3 packages to woody and
> I've been using them successfully for a few months. I am
> rather concerned about security so I sent the following
> message to the php-general mailing list. So far I have no
> response (granted less than a full day since I posted). I'm
> wondering if someone here might be able to help me with my
> questions ...
The fastest way to get answers from the PHP community is usually the IRC
channel #PHP on irc.freenode.net. It's also a good place to search for help,
and many people there run websites with free code too. Very handy place.
> I'm trying to figure out if the version of php that I am
> running is secure against all known exploits and I am finding
> that task very difficult. I haven't been able to find a
> security page on either http://www.php.net/ or http://www.zend.com/
The short answer is 'yes'. The easiest way to find out is to check the
release-specific changes for 4.3 at http://www.php.net/release_4_3_0.php
and/or the changelog at http://www.php.net/ChangeLog-4.php. From looking at
the list, I would suggest upgrading, something I'm going to do this morning
(grab the latest source and make .debs out of it).
Remember, sometimes bugfixes and performance improvements can be just as
much of a reason to upgrade as security.
> My questions are:
>
> - is php 4.2.3 vulnerable to any known security issues?
Yep.
> - is the 4.3.x branch the only one that is being maintained?
The PHP team strongly recommends using the latest version (pretty much all
the time). Security patches and so on go into new releases, not old ones
(with the exception of Debian Stable backports). So yes.
> I do not relish moving my servers from 4.2.3 to 4.3.? since I
> have encountered enough problems already with the move from
> 4.0.6 to 4.2.3.
The move from 4.0.6 to 4.2.3 is a pretty big one. 4.2.3->4.3.2 shouldn't be
nearly as big of a change (unless your code is amazingly badly written).
> Most of the problems were from sloppy coding that should
> never have worked but hey it did work with 4.0.6 and does not
> work with 4.2.3. If the code were all mine I wouldn't be so
> concerned but I don't want to be telling clients every 6-12
> months, that we're upgrading their php version and that
> things might break for them.
Tell them that you need to upgrade the PHP version because of extreme
security holes, and if you don't, hackers might be able to get hold of their
sensitive data and deface their websites. A little alarmist, but they won't
likely complain about having to fix code if it's a security issue. Remember,
the customer's always right, so always lie. And get them to write good code
in the first place.
The easiest way to ensure this is to start off from scratch enforcing proper
policy. I disabled short tags (<? echo foo ?>) in favour of the more
XML-friendly <?php ... ?> tags, as well as a dozen other tweaks in the .ini
file, to help ensure that customers were writing their code right in the
first place.
> Is there an official policy as to how long a branch is
> supported? PHP 4.2.0 is just over a year old, php 4.2.3
> about 6 months old ...
A version is supported until one comes out that is 'strongly recommended',
and then you're on your own, is I think how it works.
--Dan
Reply to: