Re: Security Issues

At 01:35 27/07/2001, Rasmus Lerdorf wrote:

I think you missed my point. People use empty() and isset() on a variable to check to see if that variable was set by the user. As such that variable is unclean and whether it came in via register_globals or not is quite irrelevant. If it is unclean it is unclean. It doesn't matter at all which mechanism (GET/POST/COOKIE) populated the data from a security perspective.

I got your point, but I disagree on it. I think that lots of users use isset() for implementing the same logic you demonstrated in your example, only in a clean, E_NOTICE-free way. I know I used to do that, Heikki says he does, and my assumption is that it's a very common practice.

I actually think that turning E_NOTICE on is going to have a huge effect on a mind boggling number of scripts, probably on the same order of magnitude as setting register_globals to off (probably less, but not that much less). I think that unless we explain explicitly and vocally why we're making these changes (register_globals and/or error level), people will just reconfigure php.ini to the old settings - I don't think they'll start running after new E_NOTICE's they suddenly get after upgrading, unless they'd know they have a good reason to. Baby-steps are needed for changes like this. We can get away with the E_NOTICE change I think. The register_globals change is much too drastic and it changes the basic nature of the language. There are plenty of people using PHP today who have no clue what an array is.

I respectfully disagree :) I think this issue is critical, and the way we handle it would show a lot on how serious we (less important) and PHP (more important) are considered. In this case, making decision according to the least common denominator doesn't make since IMHO, and we should derive our decision from a security/reliability perspective, and not the newbie-friendliness perspective. Zeev Zeev