[php-maint] [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

jpauli jpauli at php.net
Thu Feb 2 16:07:36 UTC 2012

On Thu, Feb 2, 2012 at 4:49 PM, Pierre Joye <pierre.php at gmail.com> wrote:

> hi Stefan,
> On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser <stefan at 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 :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-php-maint/attachments/20120202/8c23bd4e/attachment-0002.html>

More information about the pkg-php-maint mailing list