I agree with Ilia that removing these would help drastically reduce the security holes present in PHP applications and generally improve the image of PHP security. Or an alternative way to say that, is it would reduce the FUD being slung at PHP from ignorant people saying PHP is a security nightmare.
An embedded opcode cache I think is also essential and the surrounding $_MEMORY sounds perfect to me. All Java guys (yeah I know PHP != Java) say PHP isn't ready for the enterprise because it can't share information between processes other than arcane sessions. Having PHP become even faster also buys us not only play in the enterprise but scalability since it takes less to do what we do today. Regards, Al On Sun, 2005-08-14 at 13:11 -0400, Ilia Alshanetsky wrote: > register_globals have been deprecated since 4.2 so any modern > application should no rely on them if not for security then at least for > compatibility. Removing register globals would probably halve (if not > more) the number of security exploits (seem to number in 10s per day if > securityfocus stats are to be believed). If this is not good enough of a > reason to finally drop this legacy feature, I don't know what is. > > As far as magic_quotes_gpc goes, yes it will cause some initial pain for > people who have not considered this option to be off. But in the long > run it'll increase security by forcing people to use proper input > validation techniques, leading to better more secure code. > > Ilia > > Zeev Suraski wrote: > > 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. > > > >> 1. Remove register_globals completely > >> > >> 2. Remove magic_quotes_* > > > > > > 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. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
