It's pretty close to what I had in mind:
At 22:17 28/07/2001, Rasmus Lerdorf wrote:
>The best thing about PHP is that it has such a shallow learning curve that
>non-programmers can write web apps.
>
>The worst thing about PHP is that it has such a shallow learning curve
>that non-programmers write web apps.
>
>That is of course oversimplifying things quite a bit, but it is the root
>of the issue here.
>
>The question is not whether we should do something about this, the
>question is what we should do about it. After reading all these messages
>and talking to people about it in person, here is what I see we need to
>achieve (not necessarily in order of importance):
>
> 1. A painless migration path for existing code
By definition, it should be somewhat painful, since our working assumption
should be that there are good chances that existing code contains
exploitable bugs related to this issue. No pain no gain :)
> 2. Minimal impact on the learning curve. I really don't like requiring
> neophyte users to have to understand associative arrays before they
> can get started with PHP.
I mentioned numerous times that I don't think $foo or $_FORM['foo'] are any
different as far as the learning curve is concerned. Newbies will copy
both as-is without having to actually understand variables and/or
associative arrays.
> 3. Maximum protection for existing and new PHP apps
>
>How to get there...
>
>For 4.0.7:
>
> - We leave all default configuration settings as they are now.
> - We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
> super-globals like $GLOBALS
That's what I suggested...
> - We add a new function, somewhat like the current extract() which looks
> something like this:
>
> // Import all Get/Post/Cookie variables in to the global(/current?)
> // namespace. Function could also be called import_symbols() or
> // register_globals() although the latter would be a bit confusing
> // since it doesn't take a boolean arg like the ini version.
> // If register_globals is on already this would be a no-op
> import_globals("GPC");
>
> // Another use:
> // Only import the given variables from Post or Cookie data.
> import_globals("PC",array('user','password','first','last'));
>
> // And perhaps some globbing:
> // Import any variable with abc in its name from anywhere.
> // Could alternatively use SQL-style or perhaps real regex
> // expressions here although I think full regex support would be
> // slightly overkill and perhaps too confusing for people.
> import_globals("GPCES","*abc*");
I'm against a global function like this, but in favour of the 2nd flavour,
where you have to explicitly pass a list of variable names to import. I
also think that it should only support prefix globbing, other types of
globbing are prone to errors, and also slow to implement.
> - With the release of 4.0.7 we start hyping this security issue by
> linking to a spruced up version of the security chapter in the manual
> which describes how exactly to use these new tools.
> We could also provide a user-space implementation of the _$GET,
> $_POST... population logic and a user-space implementation of
> import_globals() so existing applications could check the PHP version
> and include our forward-compliance.inc file in order for their apps
> that conform to the new style to be backward compatible with older
> PHP installations. Or better, our .inc/.php file would do a version
> check for them.
> - We also start hyping that people who write and distribute PHP apps
> should strive to make their code E_NOTICE-clean.
Looks good.
>For 4.0.8:
>
> - If we didn't mess up in 4.0.7 and actually got something that works for
> people we consider turning on E_NOTICE by default and/or turning
> register_globals off by default.
I think that neither of these should be done in 4.0.x, as it has a too
far-reaching effect. Nothing stops us from releasing 4.1 on this very
issue, even if the only difference is just in main.c's INI list and
php.ini-dist.
>For 4.1:
> - I think a namespace approach might be interesting, although perhaps
> hard to get as granular as import_globals()
Namespaces in this case are nothing but syntactic sugar, so it's not
fundamentally different from $_FORM[var], and not any easier for newbies to
understand. Also, since we're forking the engine CVS quite soon, we don't
want to make any serious engine level changes in 4.x
>Reasoning behind something like import_globals():
>
>Large existing web apps reference these GPECS variables everywhere. There
>may literally be thousands of lines of code to change and perhaps 10's of
>thousands of lines of code to check. Simply turning off register_globals
>would make these scripts fail invisibly. The end result will be that
>people just turn register_globals back on which may even be the documented
>requirement for these distributed apps. This doesn't help anybody.
>
>However, if the authors of these apps could make their code somewhat more
>secure by simply adding:
>
> import_globals("P");
>
>to their app-wide include file and assuming they only want POST variables
>imported, then they would probably do that. It isn't much of a security
>benefit at this level, but if they took it slightly further and checked
>their forms for form elements and pulled out the valid ones and specified
>these in an array we suddenly have a whole lot more security and instead
>of changing thousands of lines, they have added perhaps 5 or 6.
As I mentioned earlier, I don't think that's a good idea to have this
function import everything by default. I think that we can support
import_globals(..., "*"), but it should display an E_NOTICE warning about
the security implications of such a move. If you really want to do it
still, you'd have to shut this warning off with a @.
Over all, I think this is much closer to what I want to see happening.
Zeev
--
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]
