On 6/29/05, Russell Nelson <[EMAIL PROTECTED]> wrote: > If 'strchr' caused your CPU's fan to stop turning, should 1) a > work-around be documented, or 2) the code fixed? If a bug in libjpeg > allows a url_fopened image to contain invalid data that elevates > privilege, should that be 1) a work-around be documented, or 2) the > code fixed? If the design of 'include' allows remote users to execute > hostile code, should that be 1) a work-around be documented, or 2) the > code fixed?
This is a stupid comparison. In the first two cases, the *bugs* would be allowing something to happen that was not even remotely related with the intention of the function/library. include() is simply doing its job, which by the way is well documented. It's not unexpeced/undesigned/buggy behaviour that it will include what it's told to. The potential for inclusion of malicious code is, if anything, a common oversight, not a design flaw. What I can suggest is one of two things... (not particularly whole-heartedly, though): 1. Create an INI_ALL variable that means something like "allow fopen wrappers in include/require" and default it to whatever is thought appropriate -- if it *is* a very common oversight, maybe false. 2. Add a "Basic considerations for your web page/application" top level that addresses the basic most common security issues. The rest of the docs could then be peppered with "security warnings" (<blink>s) where found *really* necessary. Of those, I'd probably prefer suggestion 2. > > Are you suggesting that virtually _any_ function should be > > protected against stupidity ? > > If people do stupid things with a computer, is it their fault or the > computer's fault? Personally, I always think it's the computer's > fault. So, yes, if people end up doing stupid things, it is because > the computer is wrong. Well, if you are a total end-user, I'd agree with you. But developers do need to take up some responsability to not being stupid (how much is always debatable, but you can' use such a blanket argument). -- Nelson Menezes [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
