What you ignored completely are three facts:
- register_globals=on leads to insecure code, which was demonstrated time
and time again in the past.
- Once it's off, we're going to provide methods of accessing variables
which are just as easy, and quite easier in case you access them from
functions. Having form variables register as global variables is not the
11th commandment, and it's kind of odd to see people treat it as such.
- E_NOTICE is a runtime issue, one which you would have to check under all
possible paths in your logic. That's why leaving security stuff to runtime
is always never a good idea. Setting register_globals to off gives you
development-time security.
Zeev
At 11:42 29/07/2001, Stephen van Egmond wrote:
>Rasmus Lerdorf ([EMAIL PROTECTED]) wrote:
> > Think about whether in each of these cases it would have happened if the
> > developers of the app had developed with E_NOTICE on. In a high number of
> > these cases it probably wouldn't. And if this number is close to 100%,
> > then it would point to the fact that there is another less destructive
> > solution here.
> >
> > This is why I want to go through and investigate existing PHP code and
> > have a look.
>
>I'm a user of PHP, who would describe himself as approaching "expert"
>in my knowledge.
>
>I took a suggestion from earlier in this thread, and turned off
>E_NOTICE. An excellent idea. I found a few holes in some of my code,
>which I was glad to repair, and grateful to the language for pointing
>out to me.
>
>The suggestion to turn off register_globals by default is an extremely
>bad one. It would make using PHP nothing short of a pain in the ass,
>break vast amounts of code, and not improve a whole lot. I _LIKE_ that
>I can GET or POST to a page, and the variables will still come from the
>right place.
>
>While considering the security angle, it's important to notice that
>there is a tradeoff between a secure system and a functional system,
>and that for some people, security just doesn't rate: either the
>function (e.g. register_globals) is too valuable, or the downside of a
>security failure is just not all that great. A lot of people prefer
>function over security, and would find it an unwelcome arrogance if PHP
>forced them to twiddle some settings to get it back.
>
>Finally, a small note from my PHP programming experiences:
>
>In order to code with E_ALL, idioms like this:
> if ($x)
>
> will produce warnings if $x is not set. If you don't want the
> warnings, you have to replace it with:
>
> if (isset($x) && $x) {
> }
>
> "if it's set and it's true"...? ugh.
>
>One is then tempted to look for replacement functions in the
>library, and immediately hits upon empty.
>
> if (!$empty)
>
>But as can be seen from the table at
>http://bang.dhs.org/~svanegmond/logictest.php , empty()
>returns TRUE if you hand it a boolean FALSE! Otherwise, the semantics
>of empty() are a good replacement for the warning-generating cast to
>boolean.
>
>This tends to make E_NOTIFY more trouble than it's worth... which is
>why people (including the Debian package maintainer) keep it disabled.
>
>
>Thus I recommend that empty() be fixed to return false for boolean
>values. Failing that, that a non-warning-generating logical
>equivalent of cast-to-boolean be provided.
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski <[EMAIL PROTECTED]>
CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
