Ok this is better, but it will break every single application out there. I for one think that this is unacceptable.
Well, initially - yes. With some tweaking like using automatic filters taint-safeguarding should not be too hard though (this would be one of the milestones - if we can't make it easy, the whole idea is doomed). And yes, it definitely makes it unusable as default production mode - but that's not the intended mode - not at least until people would make writing taint-safe code the routine :)
usually are synonymous with insecure. The biggest issue with safe_mode (and I suspect tainting as well) is the faulty assumption that if you enable it, you get instant security and you can quite being paranoid. Which leads to false sense of security and eventually getting hacked.
I think the issue with safe mode is the "mark unsafe" approach - which, when applied to very rich and diverse environment such as PHP is bound to fail to provide comprehensive security, thus leading to the problems you describe.
So you reverse the problem, you'd still need to examine every function and determine which of its parameters can be tainted and which cannot.
Not necessarily. If I have some obscure libWhateverFoo extension, I can just say "OK, I don't know what this does, but please filter/untaint data before feeding them to it" and for that I don't even need to touch the extension itself. This would not be 100% since the user may just not know that passing string "pleasekillme" to this extension would blow up his data center, but at least we would make user consider the fact that he passes external data to the extension and make decision. :) Also, if you talk about standard functions like strlen, demanding to untaint all data before calling strlen would be rather harsh, so yes, we would have to go over many functions. It is definitely not a half-an-hour work, and it definitely would require some deep consideration and discussion, but if we always prefer to err on the safe side - and remember, we would not need any effort to be on the safe side - I think we could make it work reasonable well.
I think we should ensure that we can provide users with reliable means to validate data via things like filter and database escaping functions
I agree.
and let people decide what and where things should be used. Doing automated validation is prone to error and we are almost guaranteed to never get it right.
No, I do not propose to do automatic validation. I only present a choice when we would ask the user to decide if the data is validated enough to be untainted - we can do it as explicit as requiring specific filter function call, or as implicit as making many filtering functions such as htmlspecialchars functions as cleaners. I tend to be somewhere in between, but that's exactly the place where more feedback would be very useful.
-- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
