Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55823
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.153 as permitted sender)
Message-ID: <4E9B2D02.2080206@sugarcrm.com>
Date: Sun, 16 Oct 2011 12:14:10 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: Rasmus Lerdorf <rasmus@lerdorf.com>, Alan Knowles <alan@akbkhome.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <4E969596.4090704@akbkhome.com>	<4E970257.2010906@sugarcrm.com> <4E977A4B.4020609@akbkhome.com>	<4E977D07.4010503@lerdorf.com> <4E9A1E93.6050804@sugarcrm.com> <CAEZPtU6R8g2-R91yO6Kd9uSCJ0mEJoO2Sx-utQqwauv6kxmFXw@mail.gmail.com>
In-Reply-To: <CAEZPtU6R8g2-R91yO6Kd9uSCJ0mEJoO2Sx-utQqwauv6kxmFXw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] is_a fix for 5.4 and HEAD
From: smalyshev@sugarcrm.com (Stas Malyshev)

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.

> 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, 
should never be written in such a way and could very well be completely 
imaginary. 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.

Changing APIs after they're public is very hard, I know it. However 
right now the API we have is bad, and if we say we would never change 
anything in order so broken code could stay broken, our API would be bad 
forever.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227