At 16:28 28/07/2001, Ron Chmara wrote:
>On Saturday, July 28, 2001, at 12:52 PM, Zeev Suraski wrote:
>>At 06:01 28/07/2001, Phil Driscoll wrote:
>>> I and no doubt thousands of others will turn
>>>register_globals on because it gives much more readable code, much less
>>>typing and does not IMHO add one jot to the security of my applications.
>>I have no doubt that thousands would turn it back on. I can't do
>>anything about it, and as I said numerous times in numerous metaphors,
>>I'm quite alright with that.
>I have roughly 2,000 files to fix before I can use it with my biggest
I understand that. This change, if implemented on existing code, requires
changes to the vast majority of existing scripts. My guess is that chances
are that at least several of these 2,000 files include issues that will be
resolved once you move to register_globals=off compatibility. Some of them
might be potentially exploited, even though perhaps none of them is.
>> I also can't imagine people avoiding PHP because variables are
>> accessed using $_FORM['foo'], instead of $foo. People are not *THAT*
>> dumb or lazy. Discussing this issue in the OSCon, Rasmus claimed that
>> right now he can teach PHP to a monkey in 3 hours, and he wouldn't want
>> to be limited only to smart Gorillas in the future. I firmly believe
>> that if a monkey can figure out $foo, $_FORM['foo'] is not going to be
>> the showstopper.
>Well, there's two *new* learning curves for the never-programmed-before
>1. Understanding arrays. The newest of the newbies are still trying to
>grok strings, and concepts like "get" or "post".
Understanding variables is not intuitive to many people either. Telling
people "use $foo" or "use $_FORM['foo']" is equally complex in my opinion,
since you can copy it, as is, without having to actually understand what
variables, or arrays, are.
>2. They have almost no examples, whatsoever, to use, for learning how to
>work with variables in this manner.
This is why I said it should be gradual. Implement the new
$_GET/$_POST/$_FORM etc. in 4.0.7, and make the default change in 4.1.0,
which would come a month or two later. We can probably get the authors of
some of the high profile PHP apps to fix them to be register_globals=off
>Both of these issues, combined, increase the "monkey" factor. Most online
>and printed tutorials available do not use HTTP_*_VARS (or any future TBI
>vars shorthand). The example code, all over php.net and zend.com, does not
>use it. Even if we encourage them to consider it "the right thing" to do,
>they don't really know how to go about doing it. I went to google.com, and
>typed in "PHP tutorials",and started looking around...
>http://hotwired.lycos.com/webmonkey/99/21/index2a.html <- Explains
>HTTP_POST_VARS, but doesn't use it.
>http://www.devshed.com/Server_Side/PHP/ <- Many tutorials, looked at a
>few, none used it.
>http://www.linuxguruz.org/z.php <- Many tutorials, looked at a few, none
>http://www.phpdeveloper.org/ <- Many tutorials, looked at a few, none used it.
>I think, perhaps, that this is one of the reasons that so much of the PHP
>codebase isn't usable with register_globals = off. The learning curve is
>steep, because it's basically undocumented, in terms of tutorials,
>examples, downloadable snippets/functions, etc. So we have a chicken/egg
>problem, where the new monkey has to make a big jump, and use a relatively
>hidden method of acccessing variables, because almost every tutorial on
>PHP is "wrong". Even the smart gorillas, (the ones writing the tutorials),
>aren't using it, probably because they never learned how/why to use it..
>If we can fix #2, #1 may not require as much effort. As it currently
>stands, if would be akin to releasing a version of PHP where we suddenly
>required them (by default, disable if needed) to change every variable
>they used from $foo to %[foo].
>So, beyond my normal ramble:
>If we were to do this, we might want to start by putting examples in
>place, if only to show users _how_ to do it. Even if we don't, we still
>need to start populating examples, if only to show users
I don't disagree with you here. I think it's important we set a goal to
get into a situation where register_globals is set to off by default. It
doesn't have to be tomorrow - after all, we did live with it for many
years. The situation is a bit more pressing now that its exploitability is
public knowledge, but we can still wait, and do this gradually while trying
to educate the userbase about this issue.
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]