Fwd: [Mediawiki-l] about requiring PHP 5.2

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: [Mediawiki-l] about requiring PHP 5.2

Chad
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 <[hidden email]>
Date: Tue, Sep 28, 2010 at 3:39 PM
Subject: [Mediawiki-l] about requiring PHP 5.2
To: [hidden email]


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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Mediawiki-l] about requiring PHP 5.2

Antoine Musso-3
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 Voultoiz<[hidden email]>
> Date: Tue, Sep 28, 2010 at 3:39 PM
> Subject: [Mediawiki-l] about requiring PHP 5.2
> To: [hidden email]
>
> 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.



_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Mediawiki-l] about requiring PHP 5.2

Niklas Laxström
On 19 October 2010 09:49, Ashar Voultoiz <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Mediawiki-l] about requiring PHP 5.2

Dmitriy Sintsov
In reply to this post by Antoine Musso-3
* Ashar Voultoiz <[hidden email]> [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 Voultoiz<[hidden email]>
> > Date: Tue, Sep 28, 2010 at 3:39 PM
> > Subject: [Mediawiki-l] about requiring PHP 5.2
> > To: [hidden email]
> >
> > 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Mediawiki-l] about requiring PHP 5.2

Chad
On Tue, Oct 19, 2010 at 5:22 AM, Dmitriy Sintsov <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Mediawiki-l] about requiring PHP 5.2

Tim Starling-2
In reply to this post by 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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Mediawiki-l] about requiring PHP 5.2

Antoine Musso-3
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 ?


--
Ashar Voultoiz


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [Mediawiki-l] about requiring PHP 5.2

Tim Starling-2
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 mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l