On Sat, Feb 4, 2012 at 11:32 AM, Pierre Joye <pierre....@gmail.com> wrote: > On Sat, Feb 4, 2012 at 10:25 AM, Stefan Esser <ste...@nopiracy.de> wrote: > >> Grow up Pierre. > > here we go again... failed. next time.... > >> See you do it again. You claim I believe EMET has been created because of >> Suhosin. I never said that. Although one of the lead developers of EMET >> compared it himself to it. >> You know some features of Suhosin are already in PHP and the HTTP response >> splitting drama shows that when you break it there is a secondary layer of >> defense that protects you in case you use Suhosin. > > I was talking about the compilation security options which are similar > (in some extends) to what Suhosin does (for some features). > >> Pierre it is time for you to come out of the delusional state. You >> repeatedly claim that everything is now superb. > > No, I said it is different and better than what you have experienced. > And anyone active today in php.net can tell you the same. > >> Do you forget PHP 5.3.7 and PHP 5.3.9 both times there were security >> vulnerabilities introduced right after the last RC. >> This is a sign that the PHP development process is still not healthy at all. > > So any software having security issues at one point or another is not healthy? > > I consider the opposite, I am very careful when I see a software > without any discovered issues for a long time, a sign of lack of > activities and users. > >> You claim I have personal issues, while I repeatedly tell you the technical >> reasons why I see it different then you. > > Sorry but I do not see technical issues in this thread, as in > technical explanations about why one given feature is actually a good > thing. I did not see any either in the past discussions. > I only say a few words and then i will be silent I tend to agree with Linus on this one "Security people are insane" http://kerneltrap.org/Linux/Pluggable_Security If there is something that needs to be done so php core will be more secure , make it in the core Not words : write RFC(docs),patches with sane techincal disscussions or a pluggable architecture with extensions and rules, something like is done with LSM http://en.wikipedia.org/wiki/Linux_Security_Modules or mod_security in apache
I vote with the Debian point of view , less patches means faster releases for php also it means more security and they are using the vanilla core (less suoshin related bugs to support) The goal is : 0 patches and use upstream as much as possible -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
