Guys, I'm sure I'll annoy the heck out of some on this list, but there's still the question whether PHP should prevent any case of dumbness on the developer side. Whatever we do, some developers out there will be way more idiotic than we can ever imagine. And if any company choses that 16-year-old PHP "professional", (who, of course, delivers the same quality code as anyone else who's doing software development for a living), and their server gets hacked or something because of weaknesses in the code, they deserve it. PHP won't get more "respect" from the business side by implementing drop dead stupid stuff like automagic validation, but rather by getting what I mentioned a few days earlier - proper Unicode support, for example, or namespaces. Spare your breath for the important stuff. Nobody needs what's just being discussed here.
Just my 0.02$, David > -----Original Message----- > From: Sean Coates [mailto:[EMAIL PROTECTED] > Sent: Sunday, February 06, 2005 10:43 PM > To: Christian Schneider > Cc: Benj Carson; internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.1 > > I'm sorry to keep dragging this out.. > > > - A default filter might help, it definitely _will_ cause problems and > > lots of programs will need fixing so it's a very double-edged sword. > > Making it easy to disable it would result in little more security as > > people running into (even minor, i.e. easily fixable) problems would do > > just that: Disable it. You guys have more experience with magic_gpc to > > judge if it's leading to more problems than it solves. > > The reason magic_quotes_* doesn't work (apart from database ambiguity, > regarding quote-escaping mechanisms) is that it may or may not be "on" > on any given server (where the code may run). Therefore, to be safe, a > good developer must do something like: $safe_a = get_magic_quotes_gpc() > ? $_GET['a'] : addslashes($_GET['a']); // absolute simplest form > > My point is that magic_quotes_gpc is completely useless in an > environment that may be shared by more than one application, or in an > environment that isn't specifically designed for the application. The > developer MUST check for it to be safe, so for a well-written > application, it might as well be always off. Also, by the time user-code > is executed, it's too late. The GPC mechanism has already run.. and > can't be un-done. > > I _do_ have experience working in a "dirty" environment where I'm > required to leave magic_quote_gpc "on" because of a legacy application, > and my new application (ie, libraries we mix in with the "old" app) must > perform the check for it (because we intend to eventually move away from > all dependency on magic_quotes_gpc, and turn it off -- but that takes > time, and money, and I have "real work" to do (according to my > management)). > > > I'm very ambivalent about the whole thing but I think it's important > > that you stop rejecting the other side's points because you're looking > > at different problems. > > Oh, to be clear, I agree that a central, "proper" way to filter input > variables is definitely a good idea. I do, however, think that this > should always be a user-space-called function. I also understand that > this WOULD be useful in a very tightly controlled environment. I don't > have any problem (and I already acknowledged that I carry no weight, > here, so take this with a big grain of salt) with sticking something > like this in PECL. > > This cannot be something that would be turned off in user-space, only > turned ON in user-space, IMO. > > Yes, I understand that no one is advocating turning filtering on by > default for all PHP apps (a la the register_globals switch), but even > the possibility that this will be turned "on" by the admins of any > significant fraction of server administrators (say 5-10%) means that all > new code I write will have to check for this if there's ANY possibility > that the "tainted" data would be useful. > > Again.. sorry for blabbing. > > S > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
