[TYPO3-core] PHP version requirement
Jigal van Hemert
jigal.van.hemert at typo3.org
Sun Mar 3 19:52:06 CET 2013
Hi,
On 3-3-2013 18:58, JoH asenau wrote:
> Well - according to our guidelines the correct way would have been:
The guidelines didn't include the concept of really major version numbers.
It was discussed that we could use the version 6.0 as an indication that
it contains bigger changes which are more likely to break during upgrades.
There have also been discussions about the LTS versions and although a
formal announcement must still appear the result is pretty clear: 4.5
support is extended a bit to have a year overlap with 6.2 LTS.
This means that organisations relying on LTS version have a full year to
prepare their upgrade.
Also having 6.2 as LTS means that the changes in 6.0 have been used in
real projects for some time, extensions are updated to support the 6.0
features and publications (snippets, articles with tips, etc.) have
appeared on how to use the new features.
> The problem many developers and users got with how things are currently
> handled in the core team is, that it seems there is a gap between the
> way some core devs think things should be working and the real life
> scenarios, especially admins still have to deal with.
There are some very conservative system administrators out there. Others
provide their systems with the latest versions of software and possible
have a range of versions available.
> Especially in enterprise environments you won't always get the cutting
> edge version of your favorite OS, PHP and other necessary software. This
> is due to the fact that there are many other pieces of software running
> in the same environment on umpteen thousands of servers and
> workstations, with some of them taking Millions of Euros to have them
> working on latest OS versions. This is something that must be taken into
> account _before_ implementing major changes to the core of a CMS that
> claims to play on enterprise level.
A pretty large and well known hosting company offers a choice between
various PHP versions to their customers (IIRC the customer can set the
PHP version for each domain). If they can do that, the system
administrators of large companies should also be able to do that.
It seems that some translate "enterprise" to "keep using outdated
software for decades".
And really, PHP 5.3.x is not "cutting edge". PHP 5.5 is in alpha state,
5.4 was released over a year ago, 5.3.7 was released on August 18, 2011.
If you don't install bugfix releases you end up with insecure servers:
Security Enhancements and Fixes in PHP 5.3.9:
Added max_input_vars directive to prevent attacks based on hash
collisions. (CVE-2011-4885)
Fixed bug #60150 (Integer overflow during the parsing of invalid
exif header). (CVE-2011-4566)
Security Fixes in PHP 5.3.10:
Fixed arbitrary remote code execution vulnerability reported by
Stefan Esser, CVE-2012-0830.
Security Enhancements for both PHP 5.3.11 and PHP 5.4.1:
Fixed bug #54374 (Insufficient validating of upload name leading to
corrupted $_FILES indices). (CVE-2012-1172).
Add open_basedir checks to readline_write_history and
readline_read_history.
And the list goes on...
Again, this "problem" is blown way out of proportion. It only happens
with extensions which still don't use the autoloader (which is available
for a long time) on installations with an old and insecure version of
PHP. There is no hard check for PHP 5.3.7; if you use a PHP version with
a lower version number which includes the patch you won't have a problem.
I think that some people try to make a mountain out of a molehill.
--
Jigal van Hemert
TYPO3 Core Team member
TYPO3 .... inspiring people to share!
Get involved: typo3.org
More information about the TYPO3-team-core
mailing list