> First of all, in general - I don't subscribe to the school of 'we broke
> something, why not break more'.  With every feature we break, we reduce
> the
> chances of people upgrading, of legacy apps working, and we reduce the
> overall success chances of the new version.  Compatibility breakup is not
> binary, it accumulates.  The more features are broken, the worse the
> situation becomes.
> 
> Given what I said above, I don't see any motivation to remove
> register_globals or magic_quotes.  I don't see how it buys us anything
> other than pissed off users and hordes of (sometimes exploitable) bugs
> that
> will result from sloppy audits.  These changes alone would mean that a
> great deal of the applications would have to be 100% audited before an
> upgrade.  Between us, developers welcoming forced labor due to upgrades is
> wishful thinking.  People never like to be forced to go over their or
> other
> people's code regardless of the circumstances.
> 
> 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.
> 
> Change the default of magic_quotes_gpc to 0 as well.

The question is: should we always care about users who are relying on
behaviour that has been deprecated for ages. And the question is: should we
feel responsible for the fact that everyone and their mother is buying a
"PHP for Dummies" book nowadays and writing apps the day after, including
some nice security vulnerabilities. If PHP always has to take care of the
weakest link in the chain (the potentially drop dead stupid "pro"
developer), we'll never get the chance to clean up legacy annoyances,
introduce new stuff and break with things that a majority of people see as a
pain in the elsewhere.

- David

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to