Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57618
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <46104CB6-A868-41C3-B8E1-F1E0AC06BCAB@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>
	<46104CB6-A868-41C3-B8E1-F1E0AC06BCAB@nopiracy.de>
Date: Thu, 2 Feb 2012 16:49:58 +0100
Message-ID: <CAEZPtU4oqvSmjU=3Oh3iuRtw5MZLaGTPLWFu-KTtq_ScKsu4Vw@mail.gmail.com>
To: Stefan Esser <stefan@nopiracy.de>
Cc: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@sury.org>, 
	657698 <657698@bugs.debian.org>, Christoph Anton Mitterer <calestyo@scientia.net>, 
	Douglas Calvert <dfc@douglasfcalvert.net>, Jesse Molina <jesse@opendreams.net>, 
	Carlos Alberto Lopez Perez <clopez@igalia.com>, PHP internals <internals@lists.php.net>, 
	Debian Developers <debian-devel@lists.debian.org>, 
	Debian PHP Maintainers <pkg-php-maint@lists.alioth.debian.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
From: pierre.php@gmail.com (Pierre Joye)

hi Stefan,

On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser <stefan@nopiracy.de> wrote:
> Hello Pierre,
>
>> About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and
>> will have bugs. This is not really hot news. That does not affect this
>> discussion.
>
> I know that for many years you have not understood the idea behind Suhosin, the concept of exploit mitigations.

Let me disagree with your way of doing things without telling me that
I do not understand what you do. It is two different concepts. I also
perfectly understand the goals of Suhosin, the technical as well as
the non technical ones. The anonymity of a project is not always
helpful.

> The only reason why Suhosin exists is because there will ALWAYS be bugs.

Indeed, so it is for Suhosin as well.

> BTW: You should really really look into the history of PHP security and check for each of the last 8 years how many features were in Suhosin and later merged into PHP because of some nasty security problem.
> You will see that at least 2 features of Suhosin per year were merged into PHP.

For one, some were not not ported but features were implemented, with
the support of their original authors. They are not related to
Suhosin, like the Blowfish support, which I ported to php with the
help of Solar Designer. Suhosin uses the same implementation.

> And there are many many good reasons, why Suhosin must be external to PHP.
> The most obvious one is that the code is clearly separated, so that not someone of the hundred PHP commiters accidently breaks a safe guard.

I would be the happiest man on Earth if PHP would have hundred active
PHP contributors. As a matter of fact, we have like 3-4 active weekly,
less than 10 yearly and maybe around 15 for the 'let commit something'
area.

While we discuss about the reasons why I do not think Suhosin is not
the right way, let start from the beginning.

I understand why you left the security team and the php project years
ago. Back then I was not on the security team, so I won't comment this
period (and I would have partially agreed with you). However, I am
part of this team since some years now and I (along with other) have
been pushing drastic changes in the way we work, for releases or
security issues in particular. You are ignoring these changes and
progresses.

For example the Release RFC (https://wiki.php.net/rfc/releaseprocess):

 . does not allow new features after x.y.0 final

 . enforce quick release when a flaw is discovered
   much easier to do as no noise commits will be present

 . many other good things

Only the two first points will drastically increase the quality and
safety of our releases. The reason is that the amount of unnecessary
commits will be null, or almost null. That kills the argument about
'hundred of commit(ers) breaking PHP'. It also helps to get fixes out
sooner rather than later.

Many features are making their way to PHP as well, on a case by case
basis. We have changed and we are on the right track since quite some
time already. If you have features that you consider that it must be
in the core, then let discuss it, on this list. But so far I failed to
see other features in Suhosin that we need to implement without having
more cons than pros.

I am also convinced that these new policies will also allow
distributions to update to the latest release of a given branches
instead of having to backport fixes to their tree. And that alone is a
huge step forward.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org