On Fri, 27 Jul 2001, Zeev Suraski wrote:

> (a) How about just setting register_globals to on?  We're not talking about
> taking this option away, for now, just turn it off by default.
> (b) As I said, if someone wants to use a gun to shoot himself in the head,
> he's welcome to do so.  The least we could do is hand him the gun safely
> pointed in the other direction, and not point it to his brain.

We know that tricks and complications don't make anything more
secure - quite the contrary, they make the applications more

We also know that good programming practices and routines help avoid
bugs. Alone, they won't help, but a person who is adviced or even
enforced to apply those practices will usually wonder: "huh, why
shouldn't I use tempnam or gets? Hmm, maybe I'll read the manual
page...". Indirectly, this also leads to changes in attitude as
the programmer starts to realize that the threats he or she is
being warned of are real and not mere paranoia of people encrypting
their swap.

The question here is whether or not register_globals is a trick
or a way to advise people of better practices.

Would anyone like to show me the design that gets innecessarily
('innecessary' meaning 'if the application wasn't well designed
in the first place, it's obvious it should be changed') complicated
when you enforce E_NOTICE and register_globals?


Everyone's emphasizing documentation on security concerns. What would
be the first things I'd like to see (or do) tre he possible security
implications for function calls or language structures in the reference
manual, next to their corresponding references. See, for example,
the bugs section of one implementation of the manual page for


Yes, sure it would be nice if there was a guide to secure programming
in PHP. Oh, but wait... I think there are some; but people don't
necessarily read them. They think that security issues don't concern

          Heikki Korpela -- [EMAIL PROTECTED] -- http://iki.fi/heko/

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]

Reply via email to