Re: dangerous handling of security bugs

Am 11.07.2010 00:39, schrieb Rasmus Lerdorf: > We do fix them, but we don't have the capacity to do point releases for > every local exploit fix. We simply don't have enough people to do that. > A shared host who is worried about local exploits need to take other > measures because most of the software in the stack is in the same boat > as PHP on exploits of this nature. Most don't even worry about them > actually. It is only because we took some steps towards trying to > secure the local environment that it is an "issue" with PHP. I understand this well But between 4 and 6 months feels way too long and sometimes there are even openbase-dir-bugs vulnerable for some months and remember it takes a time until releases are included in distributions. ____________________________ As examle (which needs a force downgrade to 4.x or disable open-basedir): - Fixed bug #48880 (Random Appearing open_basedir problem). (Rasmus, Gwynne) * 5.3.0 to 5.3.1 took 5 months * http://bugs.php.net/bug.php?id=48880 * Reported 2009-07-10 This was EXACTLY the sam eproblem i reported TWO YEARS before at 2007-10-03 http://bugs.php.net/bug.php?id=42836 for the 6.0-trunk which was commented with "Sorry, but your problem does not imply a bug in PHP itself" and clsoed as "bogus", two years later this was in a stable release and not fixexd for another 5 months You have all my understanding as developer but such things should not happen because 20 minute after initial report say "this is not a php-problem is hard enough because the time stamps are showhing very clear that "tony2001@php.net" spent no time before saying "not our problem" and such things which are breaking security-setups should not be ignored ____________________________ 30 Jun 2009, PHP 5.3.0 19 Nov 2009, PHP 5.3.1 04 Mar 2010, PHP 5.3.2

Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc