Crossposting to php-internals too since those are the guys who receive the bugreports...
Debian unstable packages has recently disabled suhosin patch by default (it is still kept as optional part which could be enabled at compile time). I am trying to summarize the reasons why I have decided to disable suhosin patch here. Please keep the discussion civil and on the technical level and if you want to engage in deeper discussion please try to keep it isolated in pkg-php-ma...@lists.alioth.debian.org and 657...@bugs.debian.org, so we don't flood cross-post. [Sorry for such huge initial cross-post.] There are already some reasons listed here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657698#15 The manpower issue which was mentioned several times is not the only one (it mainly comes to mind if we have to keep to sets of packages w/ and w/o suhosin). Although the pkg-php team is always looking for new victims^Umembers. I'll try even harder to list more reasons, why I have changed my mind over a time regarding the suhosin patch: 1. Suhosin patch has an impact on the speed and memory usage. This has been documented and even author admits it [1]. 2. It doesn't help our users when reporting bugs to upstream - the usual answer is - try if that happens with vanilla php. 3. Stefan's relationships with PHP upstream (and vice versa)[1] isn't helping very much - and I think we (pkg-php) have improved our relationship with upstream in past few years a lot. 4. PHP has improved a lot, in fact I haven't seen a canary report in past few years (probably 5.3.x). Also there are very few segfaults reported in 5.3 (compared to 5.2 which was a living nightmare from what I remember). 5. Keeping our code close to upstream and to other linux distros (Fedora - no, Suse - optional) is a way how to provide our users with consistent behaviour across the Linux ecosystem. My personal feeling is that most people see suhosin as "this is about security, thus it must be good". This combined with bad PHP security history makes everybody feel insecure when suhosin was removed, but the real question is if the suhosin is still really helping with PHP security or it is just a burden in the general installations now. I have walked the bug list for 5.3 mentioning suhosin[2] to actually at least partially support what I have just said. I have found few bugs where suhosin was causing a problems ([3],[4]) and a handful of bugs with "have suhosin, cannot help". I know this isn't (and can't be) a definitive list, but it just show that P.S.: Also see stas reply[5] about valgrind. Links: 1. http://www.hardened-php.net/hphp/faq.html#why_is_hardening-patch_not_part_of_php 2. https://bugs.php.net/search.php?search_for=suhosin&boolean=0&limit=90&order_by=&direction=DESC&cmd=display&status=All&bug_type=All&project=PHP&php_os=&phpver=5.3&cve_id=&assign=&author_email=&bug_age=0&bug_updated=0 3. https://bugs.php.net/bug.php?id=60216 4. https://bugs.php.net/bug.php?id=60935 5. http://www.suspekt.org/2008/10/12/suhosin-canary-mismatch-on-efree-heap-overflow-detected/ -- Ondřej Surý <ond...@sury.org> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
