Bug 453235

This patch can be included in 2 ways

1/ a patch php binary (which is what Debian provides)

2/ a pecl extension (which is under review : see #426985)

Only the first provides all the security features.

Another question is if it should be enabled on install ?

We probably need to run this through the security team and then enable this by
default if they agree. I am CC'ing Josh Bressers

triaged

*** This bug has been marked as a duplicate of 250105 ***

I'm personally not very comfortable including a third party patch to our PHP. 
These usually prove to be anchors around your neck when spread out over time.
While PHP has had its share of flaws, none of them are all that bad really.  The
real issue is crappy PHP aplications.  So this raises some questions in my mind.

1) What does Joe think (I'm currently leaning toward add it as a plugin if you
want it)

2) What has this stopped in the past.  It's easy to claim it works, I want to
know what it really does, and what flaws has it stopped.

3) Why isn't this in PHP upstream?

I'm not worried about what other distributions are doing.  The only question we
should ask is "is the work needed to maintain this worth the protection it will
provide".  I don't know the answer to that.

1) The plugin isn't a alternative to the patch. They are meant to be used in
combination with each other.

2) http://www.hardened-php.net/advisories.15.html

3) http://blog.php-security.org/archives/61-Retired-from-securityphp.net.html

Neither of those links add any value to this bug.  My questions are quite to the
point and are valid concerns regarding this out of band third party patch.

So let me explain again, the advisories in the website forum lists
vulnerabilities and details how the patch mitigates them. The second link talks
about the author of this patch resigning from the PHP security team. The patch
doesn't get upstream due to this politics. Hope that helps.

From looking over them, the last advisory that mentions Suhosin is from 2006,
none of the 2007 advisories mention Suhosin at all.  Those appear to be
advisories for flaws found by the Hardened PHP project, not for flaws Suhosin
protects against.

If the patch won't go upstream due to politics, why do we want to include it? 
Wouldn't it make more sense to put our effort into getting it upstream rather
than  adding it as a third party add-on?

Yes, that might indeed be the right path forward but I do know understand the
patch enough to comment on how feasible that is. Perhaps the maintainer can talk
to upstream?

Note that the Suhosin extension is independent of the patch and has already been
proposed for inclusion in Fedora, see bug 426985.

My comment in bug 250105 comment 2 stands.  Suhosin does not create a "sandbox"
in which untrusted PHP code can run safely; it doesn't fundamentally change the
PHP security model.  I think that the performance trade-off necessary in trying
to add the canaries etc in Stefan's patch has been explicitly rejected upstream;
so I don't see how my time could be spent on this wisely.

I agree with Joe; if the patches to PHP source are useful, they should be
applied upstream. I don't think it's our job to make a difficult decision about
this low-level patch, and it will create work maintaining it especially if
upstream is slow updating the patch, the old one doesn't apply against a new
release and we need to get an updated PHP release out for security. Ironically
that could make the security situation worse.

By all means let's have the plugin in bug #426985 but let's not have this patch.