Forwarding to wikitech-l, needs more audience.
I've no love for outdated software, so I'm firmly in the +1 camp.
-Chad
---------- Forwarded message ---------- From: Ashar Voultoiz hashar+wmf@free.fr Date: Tue, Sep 28, 2010 at 3:39 PM Subject: [Mediawiki-l] about requiring PHP 5.2 To: mediawiki-l@lists.wikimedia.org
Hello,
Looking at INSTALL it seems we are still supporting PHP version 5.1 which is 5 years old in a couple of weeks. This is getting old and prevents developers from using some new features.
Ideally we could raise it to 5.3 to get Namespace support, closures but that might be to early since most webhost probably still use 5.2.x.
Would it be possible to consider raising the requirement to at least 5.2.0 ? This would give us native JSON support and most probably the filter extension enabled by default. The later can be used to speed up the input validation.
cheers,
-- Ashar Voultoiz
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
Nobody seems to care about it :p
On 08/10/10 23:25, Chad wrote:
Forwarding to wikitech-l, needs more audience.
I've no love for outdated software, so I'm firmly in the +1 camp.
-Chad
---------- Forwarded message ---------- From: Ashar Voultoizhashar+wmf@free.fr Date: Tue, Sep 28, 2010 at 3:39 PM Subject: [Mediawiki-l] about requiring PHP 5.2 To: mediawiki-l@lists.wikimedia.org
Hello,
Looking at INSTALL it seems we are still supporting PHP version 5.1 which is 5 years old in a couple of weeks. This is getting old and prevents developers from using some new features.
Ideally we could raise it to 5.3 to get Namespace support, closures but that might be to early since most webhost probably still use 5.2.x.
Would it be possible to consider raising the requirement to at least 5.2.0 ? This would give us native JSON support and most probably the filter extension enabled by default. The later can be used to speed up the input validation.
On 19 October 2010 09:49, Ashar Voultoiz hashar+wmf@free.fr wrote:
Nobody seems to care about it :p
Yikes, top-posting!
Having a 5.2.x as requirement for 1.17 could be a good incentive for the rest to upgrade PHP to get goodies like resource loader. But on the other hand I think we should first release 1.17 and then up the requirements. Otherwise we might need to support 1.16 for a lot longer, like what happened with 1.6 and PHP4.
-Niklas
* Ashar Voultoiz hashar+wmf@free.fr [Tue, 19 Oct 2010 08:49:47 +0200]:
Nobody seems to care about it :p
On 08/10/10 23:25, Chad wrote:
Forwarding to wikitech-l, needs more audience.
I've no love for outdated software, so I'm firmly in the +1 camp.
-Chad
---------- Forwarded message ---------- From: Ashar Voultoizhashar+wmf@free.fr Date: Tue, Sep 28, 2010 at 3:39 PM Subject: [Mediawiki-l] about requiring PHP 5.2 To: mediawiki-l@lists.wikimedia.org
Hello,
Looking at INSTALL it seems we are still supporting PHP version 5.1 which is 5 years old in a couple of weeks. This is getting old and prevents developers from using some new features.
Ideally we could raise it to 5.3 to get Namespace support, closures
but
that might be to early since most webhost probably still use 5.2.x.
Would it be possible to consider raising the requirement to at least 5.2.0 ? This would give us native JSON support and most probably
the
filter extension enabled by default. The later can be used to speed
up
the input validation.
One of my hosters has FreeBSD and early php5.2 and no native JSON support. I believe it's not guaranteed to have JSON. However, 5.2 of course is better and more stable than 5.1. Dmitriy
On Tue, Oct 19, 2010 at 5:22 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
One of my hosters has FreeBSD and early php5.2 and no native JSON support. I believe it's not guaranteed to have JSON. However, 5.2 of course is better and more stable than 5.1. Dmitriy
We have fallback code in case JSON support is missing, so this shouldn't be a problem.
-Chad
Ashar Voultoiz wrote:
Looking at INSTALL it seems we are still supporting PHP version 5.1 which is 5 years old in a couple of weeks. This is getting old and prevents developers from using some new features.
Ideally we could raise it to 5.3 to get Namespace support, closures but that might be to early since most webhost probably still use 5.2.x.
Would it be possible to consider raising the requirement to at least 5.2.0 ? This would give us native JSON support and most probably the filter extension enabled by default. The later can be used to speed up the input validation.
Apparently WordPress had this discussion in July, but unlike us, they had usage statistics:
http://wpdevel.wordpress.com/2010/07/09/suggest-topics-for-the-july-15-2010-dev/
For WordPress 2.7+ as of July, the version distribution was:
4.3 – 1.3% 4.4 – 6.3% 5.0 – 0.1% 5.1 – 3.5% 5.2 – 85.4% 5.3 – 3.4%
I don't think JSON support is particularly important since it can easily be simulated, and I don't think you should use the filter extension in MediaWiki, regardless of whether it is supported.
However, I can think of a good argument for moving to PHP 5.2, which is to stop the high rate of bit rot in 5.1 support. In particular, support for callbacks with double-colons to indicate static method calls:
call_user_func( 'Foo::bar' )
was added in PHP 5.2.3. Developers often use these, and don't realise that they are breaking PHP 5.1 support. So I think there's a good argument for making 5.2.3 the minimum.
Another example of bit rot: the trunk has 3 calls to array_fill_keys(), with no simulation in GlobalFunctions.php; it was added in 5.2.0. Developers should really check the versions in the manual when they use a function, otherwise 5.2.x will soon be broken as well, in favour of 5.3.x. But in theory we can weed out calls to newly-added functions with grep. The 5.2.3 callback change was more subtle.
-- Tim Starling
On 03/11/10 08:10, Tim Starling wrote:
I don't think JSON support is particularly important since it can easily be simulated, and I don't think you should use the filter extension in MediaWiki, regardless of whether it is supported.
Just out of curiosity, what is wrong with the filter extension ? From far away, it looks like it could be used to speed up some of our sanitization checks.
However, I can think of a good argument for moving to PHP 5.2, which is to stop the high rate of bit rot in 5.1 support. n particular, support for callbacks with double-colons to indicate static method calls:
call_user_func( 'Foo::bar' )
was added in PHP 5.2.3. Developers often use these, and don't realise that they are breaking PHP 5.1 support. So I think there's a good argument for making 5.2.3 the minimum.
Another example of bit rot: the trunk has 3 calls to array_fill_keys(), with no simulation in GlobalFunctions.php;
<snip>
Those are good points, Tim. Thanks! I like how PHP changes language definitions between minor versions.
Anyway, should we start right now to require 5.2.3 ?
On 03/11/10 18:43, Ashar Voultoiz wrote:
On 03/11/10 08:10, Tim Starling wrote:
I don't think JSON support is particularly important since it can easily be simulated, and I don't think you should use the filter extension in MediaWiki, regardless of whether it is supported.
Just out of curiosity, what is wrong with the filter extension ? From far away, it looks like it could be used to speed up some of our sanitization checks.
filter_input() can't be used because it skips the abstractions in $wgRequest. filter_var() could theoretically be used, but it seems to me that you would very rarely want to do so.
Many of the filters are poorly-documented and so are subject to change. For instance, you wouldn't want to use FILTER_VALIDATE_EMAIL, because it's not clear what it does exactly, and whatever it is, it's probably not the same as MediaWiki's view of an email address, per User::isValidEmailAddr(). Even if it was the same, it might change in the next minor release, breaking existing MediaWiki installations.
The escaping filters such as FILTER_SANITIZE_ENCODED and FILTER_SANITIZE_SPECIAL_CHARS have perfectly good equivalents already (urlencode() and htmlspecialchars()). The point of having them in the filter module is to encourage input-side escaping. However, I'm strongly against any kind of input-side escaping since it's hard to review and often leads to security vulnerabilities.
Similarly, the stripping filters, such as FILTER_SANITIZE_STRING and FILTER_SANITIZE_URL, are examples of incorrect security policy. When applied on the input side as intended, they break the application logic, silently mangling user input, but they often fail to protect against security vulnerabilties. The false sense of security they give leads developers to forget output-side escaping, with disasterous results whenever the stripping function was not designed for the kind of output done.
For example, this is OK:
$foo = filter_input( INPUT_GET, 'foo', FILTER_SANITIZE_STRING ); $bar = filter_input( INPUT_GET, 'foo', FILTER_SANITIZE_MAGIC_QUOTES ); echo $foo; $db->query( "select '$bar' limit 1" );
But this is XSS:
$url = filter_input( INPUT_GET, 'url', FILTER_SANITIZE_URL ); echo "<img src="$url"/>";
That just leaves the simplest filters, like FILTER_VALIDATE_FLOAT. They're the only ones that I think could have any potential usefulness. But you'd want to have a very good reason for using them, since code which uses an unfamiliar module will typically be harder for regular MediaWiki developers to read and interpret than code which just uses basic functions and regexes.
-- Tim Starling
wikitech-l@lists.wikimedia.org