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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
