Zeev Suraski wrote:
> If we are to do anything about register_globals, perhaps we can change
> the name of the directive to something else (e.g. unprotected_globals),
> and of course keep its default 0. Admins will have to make an informed
> decision to turn it on again, and we can speak against it as strongly as
> we want in an upgrade guide.
I think that would be a really bad idea. Code that tries to be portable
and uses ini_get('register_globals') would now be lying to us? Or do we
add unprotected_globals as an alias? So instead of getting rid of it,
we now have two directives that mean the same thing? I think we took
the major BC breakage hit when we turned it off. And a simple
extract($_REQUEST,EXTR_SKIP) restores these in an app that needs it, so
it isn't really a question of auditing lots of code, just knowing what
needs it and what doesn't.
> Change the default of magic_quotes_gpc to 0 as well.
>
>> 3. Add input filter extension which will include a mechanism for
>> application developers to very easily turn it off which would swap
>> the raw GPC arrays back in case the site had it turned on by default.
>
> Sounds good.
Doesn't really make sense to add the filter extension and keep
magic_quotes_gpc. They would be stepping on each others toes. A
magic_quotes_gpc filter would be trivial to add to the filter extension.
We could even add a slight hack that would set the magic_quotes_gpc ini
var so apps checking for it with ini_get() would see it if it was
implemented via the filter extension.
I have probably been one of the bigger proponents of not breaking BC
over the years. And I did choose my list of things quite carefully to
avoid wholesale breakage. I am completely against changing function
names or re-ordering arguments since this is purely aesthetic. However,
there isn't much point in deprecating things if we are never going to
remove anything and I don't think pushing register_globals and
magic_quotes_gpc down to the application level making them the exception
rather than the rule is much of a break. Just about every portable app
I have seen lately check for these, so none of those will break since
ini_get('register_globals') will simply return false all the time now.
Many more don't even check anymore and just assume it is off which
becomes a problem on servers where the admin has one or two old apps
that need it on and turn it on for the whole server because of it. The
security problems often occur in the non-register_globals apps on such a
server because the authors never even considered that they would be on.
I think a one-liner fix or an auto_prepend to these old apps is worth
the hassle.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
