Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57619
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.42 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAEZPtU4oqvSmjU=3Oh3iuRtw5MZLaGTPLWFu-KTtq_ScKsu4Vw@mail.gmail.com>
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> <CAEZPtU4oqvSmjU=3Oh3iuRtw5MZLaGTPLWFu-KTtq_ScKsu4Vw@mail.gmail.com>
Date: Thu, 2 Feb 2012 17:06:48 +0100
Message-ID: <CAMUwpuTukEj+QCiKhAKTcCLqLXmxUkrkZidjHnU9jOfcgeNFog@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Stefan Esser <stefan@nopiracy.de>, =?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: multipart/alternative; boundary=0016e64c39588b6a0f04b7fd64ee
Subject: Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds
From: jpauli@php.net (jpauli)

--0016e64c39588b6a0f04b7fd64ee
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 2, 2012 at 4:49 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
In fact, I agree that it'd be a good idea to discuss more widely PHP
Security , why not through specific RFCs, with POCs of each ideas/concepts
, so that people could comment on them, and approve/decline the
concepts/patches :)

Julien.P

--0016e64c39588b6a0f04b7fd64ee--