<div class="gmail_quote">On Thu, Feb 2, 2012 at 4:49 PM, Pierre Joye <span dir="ltr"><<a href="mailto:pierre.php@gmail.com">pierre.php@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

hi Stefan,<br>
<div class="im"><br>
On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser <<a href="mailto:stefan@nopiracy.de">stefan@nopiracy.de</a>> wrote:<br>
> Hello Pierre,<br>
><br>
>> About the current flaw affecting 5.3/4, PHP and suhosin had bugs, and<br>
>> will have bugs. This is not really hot news. That does not affect this<br>
>> discussion.<br>
><br>
> I know that for many years you have not understood the idea behind Suhosin, the concept of exploit mitigations.<br>
<br>
</div>Let me disagree with your way of doing things without telling me that<br>
I do not understand what you do. It is two different concepts. I also<br>
perfectly understand the goals of Suhosin, the technical as well as<br>
the non technical ones. The anonymity of a project is not always<br>
helpful.<br>
<div class="im"><br>
> The only reason why Suhosin exists is because there will ALWAYS be bugs.<br>
<br>
</div>Indeed, so it is for Suhosin as well.<br>
<div class="im"><br>
> 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.<br>
> You will see that at least 2 features of Suhosin per year were merged into PHP.<br>
<br>
</div>For one, some were not not ported but features were implemented, with<br>
the support of their original authors. They are not related to<br>
Suhosin, like the Blowfish support, which I ported to php with the<br>
help of Solar Designer. Suhosin uses the same implementation.<br>
<div class="im"><br>
> And there are many many good reasons, why Suhosin must be external to PHP.<br>
> 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.<br>
<br>
</div>I would be the happiest man on Earth if PHP would have hundred active<br>
PHP contributors. As a matter of fact, we have like 3-4 active weekly,<br>
less than 10 yearly and maybe around 15 for the 'let commit something'<br>
area.<br>
<br>
While we discuss about the reasons why I do not think Suhosin is not<br>
the right way, let start from the beginning.<br>
<br>
I understand why you left the security team and the php project years<br>
ago. Back then I was not on the security team, so I won't comment this<br>
period (and I would have partially agreed with you). However, I am<br>
part of this team since some years now and I (along with other) have<br>
been pushing drastic changes in the way we work, for releases or<br>
security issues in particular. You are ignoring these changes and<br>
progresses.<br>
<br>
For example the Release RFC (<a href="https://wiki.php.net/rfc/releaseprocess" target="_blank">https://wiki.php.net/rfc/releaseprocess</a>):<br>
<br>
 . does not allow new features after x.y.0 final<br>
<br>
 . enforce quick release when a flaw is discovered<br>
   much easier to do as no noise commits will be present<br>
<br>
 . many other good things<br>
<br>
Only the two first points will drastically increase the quality and<br>
safety of our releases. The reason is that the amount of unnecessary<br>
commits will be null, or almost null. That kills the argument about<br>
'hundred of commit(ers) breaking PHP'. It also helps to get fixes out<br>
sooner rather than later.<br>
<br>
Many features are making their way to PHP as well, on a case by case<br>
basis. We have changed and we are on the right track since quite some<br>
time already. If you have features that you consider that it must be<br>
in the core, then let discuss it, on this list. But so far I failed to<br>
see other features in Suhosin that we need to implement without having<br>
more cons than pros.<br>
<br>
I am also convinced that these new policies will also allow<br>
distributions to update to the latest release of a given branches<br>
instead of having to backport fixes to their tree. And that alone is a<br>
huge step forward.<br>
<div class="im HOEnZb"><br>
Cheers,<br>
--<br>
Pierre<br>
<br>
@pierrejoye | <a href="http://blog.thepimp.net" target="_blank">http://blog.thepimp.net</a> | <a href="http://www.libgd.org" target="_blank">http://www.libgd.org</a><br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
PHP Internals - PHP Runtime Development Mailing List<br>
To unsubscribe, visit: <a href="http://www.php.net/unsub.php" target="_blank">http://www.php.net/unsub.php</a><br>
<br>
</div></div></blockquote></div><br><div>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 :)</div>

<div><br></div><div>Julien.P</div><div><br></div>