Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55824
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4E9B2D02.2080206@sugarcrm.com>
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>
	<4E9B2D02.2080206@sugarcrm.com>
Date: Sun, 16 Oct 2011 23:14:06 +0200
Message-ID: <CAEZPtU5O=OC7nT_qRevZ42D1_6M_fw9wzVVme6Q=F6_JdBe1BA@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 9:14 PM, Stas Malyshev <smalyshev@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