Re: Proposal

UNSUBSCRIBE ME PLEASE!!!!!!!!!!!!!! Zeev Suraski schrieb: > 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: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net