On Sun, Oct 16, 2011 at 9:14 PM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > > On 10/16/11 3:39 AM, Pierre Joye wrote: >> >> There was example codes in previous discussions, here and on security. >> The document used for the CVE assignment has some as well. >> >> >> http://www.byte.nl/blog/2011/09/23/security-bug-in-is_a-function-in-php-5-3-7-5-3-8/ >> https://bugs.php.net/bug.php?id=55475 >> https://bugzilla.redhat.com/show_bug.cgi?id=741020 > > I know about these, this is why I specifically asked for real-life examples. > And yes, it does matter - if it's completely invented example, it's one > thing, if it's part of live widely deployed code, it's another.
They are not completely invented examples. Or do you ask for any single issue we have to show the real life examples? In short, we do not. >> It is not correct. If a code, for whatever reason, was working fine >> until now then there is no reason one has to change it to make it work >> again, or even worst in this case, to make it safe again. >> >> And yes, I agree that this kind of code is ugly and should not have >> written that way, but we cannot do anything but be sure that we don't >> make this code even worst. > > The problem is not the beauty of such code, but the fact that we are > breaking our APIs to match somebody's code that is insecure anyway, The fact is that we have many broken APIs we can't fix for BC reasons. We have to live with that in the 5.x serie. > should never be written in such a way and could very well be completely > imaginary. could, should, would, it does not change the problem for a single yota. We can't have a variable ways to work with BC and security issues. We simply can't as we have no way, absolutely no way, to be sure that a given case is not used (widely or not). > The reason to change such code is exactly that this code is insecure and > broken, and the fact that nobody could break it by one specific way doesn't > mean there aren't other ways. We have discussed that already on security, I barely see a reason to begin this discussion again. There is a clear possible security problem, clearly identified and not present before this "fix" was applied. It is easy to fix and does not make PHP worst or better than what it is now but only ensure that there is no BC, or new security issues. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
