Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55816
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E9A1E93.6050804@sugarcrm.com>
References: <4E969596.4090704@akbkhome.com>
	<4E970257.2010906@sugarcrm.com>
	<4E977A4B.4020609@akbkhome.com>
	<4E977D07.4010503@lerdorf.com>
	<4E9A1E93.6050804@sugarcrm.com>
Date: Sun, 16 Oct 2011 12:39:15 +0200
Message-ID: <CAEZPtU6R8g2-R91yO6Kd9uSCJ0mEJoO2Sx-utQqwauv6kxmFXw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, Alan Knowles <alan@akbkhome.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] is_a fix for 5.4 and HEAD
From: pierre.php@gmail.com (Pierre Joye)

On Sun, Oct 16, 2011 at 2:00 AM, Stas Malyshev <smalyshev@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