Okay, I'm leaving for vacation in 7 hours. I'd like to bring the
'include' discussion to an end. There have been a lot of weak points
made, e.g. "Yeah, it's a problem; that's why we documented it".
Rather than re-dismiss them, I'll ignore them in favor of addressing
the strongest ones.
o This problem is decreasing in frequency according to vulnerability
reports, so there is no urgency about fixing it.
People aren't going to report vulnerabilities when they are
persistently told "That's not a bug; that's a feature!"
Vulnerability reports are self-selected and thus are not a good
sample for even the most rudimentary statistical analysis like "the
rate is decreasing."
o If you trust user data you are eventually going to get screwed; if
not by 'include' then by something else.
It's not obvious that 'include' can be convinced to execute remote
code.
o We're not fixing it.
This is simultaneously a weak point and a very strong one.
Obviously the maintainer of a codebase can publish code with any
number of vulnerabilities in it and nobody can do anything about it
other than to stop using the code. On the other hand, the code is
still vulnerable, so not fixing it is no solution.
o We *are* fixing it, but just not your way.
Depending on the exact nature of the fix, this may be a reasonable
response. The fix needs to address the problem that 'include' has
hidden sharp edges. If it merely offers a way to optionally cover the
sharp edge, then it won't fix the problem. Other optional fixes
(e.g. allow_url_fopen==false) haven't yet fixed the problem. Why
should this one fix it?
--
--My blog is at blog.russnelson.com | If you want to find
Crynwr sells support for free software | PGPok | injustice in economic
521 Pleasant Valley Rd. | +1 315-323-1241 | affairs, look for the
Potsdam, NY 13676-3213 | | hand of a legislator.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
