On Sun, Oct 16, 2011 at 2:00 AM, Stas Malyshev <smalys...@sugarcrm.com> wrote: > Hi! > > On 10/13/11 5:06 PM, Rasmus Lerdorf wrote: >> >> I agree that it is slightly messy, but we have painted ourselves into a >> bit of a corner with the 5.3 mess. Stas, the whole point here is that >> changing the is_a() default in 5.3 caused huge problems, including >> security ones, so setting allow_string to false by default fixes that BC > > I've read complaints about is potentially causing security problems, but is > there code out there that was OK before and has security problem with this > change? I mean, a real-life app?
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 Now whether this exact use case is used in a real life app, nobody can say it, but it really does not matter (or one can dig codesearch&co to find some). > I'm thinking maybe we should have this options - but maybe have both > defaults set to true? This way if you have buggy code and you absolutely > refuse to move to proper code you can easily fix it by putting false where > needed, but at least our API is not broken anymore. 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. 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
