hi Stefan, On Thu, Feb 2, 2012 at 3:14 PM, Stefan Esser <ste...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEZPtU4oqvSmjU=3oh3iurtw5mzlagtplwfu-kttq_scksu...@mail.gmail.com
