Hello Pierre, >> 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).
Actually no. The key security iprovements in Suhosin-Patch have nothing todo with anything the compile time options of VC offer. Suhosin does not attempt to do Stack Protection, or ASLR or NX. The only thing that might be a compile time option is support for %n in format strings. I think VC or libs do not allow that anymore. The problem with PHP is that is does a lot of things like implementing their own heap manager from scratch, which is a security nightmare and something a compiler cannot protect you from. >> 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? Again. We are not talking about software having security issues. We are talking about software with 4,5 or whatever number of release candidates. And then the security vulnerability is caused by an unreviewed commit to the code after the last release candidate and before final. This is bad. And there is no point arguing this fact. > 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. Of course it might mean exactly this. But it could also mean that the software simply works and does not have major problems. >> 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 repeatedly tell you that a second layer of defense outside of the main product is a good thing. You disagree. However defense in depth is widely accepted as the way to go. Also having canaries in memory managers, while using more memory is a known valid mitigation against buffer overflows. You can look it up on the internet. Having pointer obfuscation is also a mitigation you see in glibc and Microsoft (even in Internet Explorer). Whitelisting of destructors is a mitigation based on whitelisting. These are all basic prinicples of security mitigations. Why is there a need to write up RFC about these things. They are widely accepted by other software vendors/products. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
