Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57692
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nopiracy.de from 81.169.146.161 cause and error)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
In-Reply-To: <4F2D01A0.3050000@sugarcrm.com>
Date: Sat, 4 Feb 2012 11:13:04 +0100
Cc: PHP internals <internals@lists.php.net>,
 "security@php.net" <security@php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <2AE2BBB6-2AAC-40D2-9083-6CB1DD95454A@nopiracy.de>
References: <CALjhHG_wYvJn-Z+x9fJUi+dgmZ+Ha9BD54N5VwhneJM4sg1xBQ@mail.gmail.com> <5FB5CFDA-6FE8-4C20-A9B9-7844ED96659B@nopiracy.de> <CAEZPtU7jtQTDNpUovxxnDdRunjH9BOdX=WbS8JcGz+5Wkz8ocw@mail.gmail.com> <4F2A9378.70803@thelounge.net> <4F2AC9CA.2070308@sugarcrm.com> <4F2B2ED8.4050900@jimdo.com> <72878E6C-4C17-4D94-9F73-1446769247E1@nopiracy.de> <CAEZPtU5CP3GqUnKsxx51-ieHAdGh=ySvZCWhhAwa0kwuNG6Bhg@mail.gmail.com> <A33C7716-F355-455E-863D-5458205C3208@nopiracy.de> <4F2CEA7E.9010906@sugarcrm.com> <9684A843-5A7F-43BB-BFC2-86F34E27EC3B@nopiracy.de> <CAEZPtU6eYxWM+hL4RzO_Mpx7GgDe3cxJNbZXbwD2MXdFUPS+aA@mail.gmail.com> <A3FA10BF-D660-4705-BBF0-1AF8F9D27C35@nopiracy.de> <CAEZPtU7qyezW44HJbHS=wz5+2_O4PJywg8=Oafhn1JBLonQmwA@mail.gmail.com> <BB9858AE-5AC9-4602-9D6A-2240E0F497AD@nopiracy.de> <4F2D01A0.3050000@sugarcrm.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
From: stefan@nopiracy.de (Stefan Esser)

Hi,

>> This is bad. And there is no point arguing this fact.
>=20
> Yes, this was bad. Agreed. It was a mistake. Mistakes happen. We fixed
> it and hopefully learned from it.

Yes mistakes do happen to everyone and we all hope to learn from them.
And some of us like to buy insurances so that there is protection in =
case anything goes wrong.
And because we know that everyone makes mistakes we add additional =
layers of protection.
In case of PHP this is Suhosin. In case of Apache this is mod_security. =
In case of Linux it is better Grsecurity (and not the other stuff).
And in case of webservers in general people buy web application =
firewalls.

>> These are all basic prinicples of security mitigations. Why is there
>> a need to write up RFC about these things. They are widely accepted
>> by other software vendors/products.
>=20
> Because there's a difference between principles and applying them in a =
particular manner in particular patch to particular software. The =
responsibility of core PHP developers it to evaluate the specific =
solutions and patches and decide if they are good or not. Regardless of =
how well or badly it was done in specific cases in the past, this is =
what should be done. If the author of the patch doesn't want to do this =
- well, ok, so he would have his patch and we probably won't, unless we =
find other ways to do it - maybe even the worst way possible, by having =
security problem illuminate the need - but I see no way around it.

The patches are available for everyone. You can download them at =
http://suhosin.org - also everyone can use them for free. Everyone can =
just take them and merge them into PHP.
But it will not be me. As I previously stated I can live with a few =
percent less performance or more memory usage due to memory canaries. =
(The later can actually be largely improved and I have plans to do it =
somewhen in the next months). However I know that memory canaries will =
never go into PHP mainline.

And knowing that tells me that I have to keep Suhosin anyway as a =
project. And therefore people should use it.
And all those that maybe cannot live with this impact can already use =
Suhosin today and just disable the memory canaries via environment =
variables.=20

Regards,
Stefan