# Suhosin patch disabled by default in Debian php5 builds - Thread: https://externals.io/message/57610 - Original archive: https://news-web.php.net/php.internals/57610 - Started by ondrej@sury.org on 2012-02-02T12:55:20+00:00 - Messages: 76 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/57610.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #57610 — ondrej@sury.org — 2012-02-02T12:55:20+00:00 URL: https://externals.io/message/57610#57610 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-maint@lists.alioth.debian.org and 657698@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ý 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. considering the fact that you write this email the very same day that a remote code execution vulnerability in PHP is found that is easy to exploit from remote and is greatly mitigated by the use of Suhosin you look pretty stupid. (In case of usage of Suhosin-Extension in default config, it is even completely killed). Just saying. Regards, Stefan Esser --- ## #57613 — Pierre Joye — 2012-02-02T13:38:47+00:00 URL: https://externals.io/message/57610#57613 · In reply to: #57612 Hi Stefan, > Hello Ondřej, > > > […] > > considering the fact that you write this email the very same day that a remote code execution vulnerability in PHP is found that is easy to exploit from remote and is greatly mitigated by the use of Suhosin you look pretty stupid. (In case of usage of Suhosin-Extension in default config, it is even completely killed). Another very important part of Ondrej's email was: "Please keep the discussion civil and on the technical level" And at this point, I may suggest you to keep such posts for yourself. 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, for one, like the idea to finally see distros droping Suhosin and focus on making PHP itself better and safer instead of distracting us and our users with custom patches or extensions. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57614 — Reindl Harald — 2012-02-02T13:45:28+00:00 URL: https://externals.io/message/57610#57614 · In reply to: #57613 Am 02.02.2012 14:38, schrieb Pierre Joye: > 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, for one, like the idea to finally see distros droping Suhosin and > focus on making PHP itself better and safer instead of distracting us > and our users with custom patches or extensions. yes, but suhosin-extension and hardening patch exists since many years the question from a normal user: why are these things not included in the core? especially the option to disable function by directory while "disable_functions" is stupidity shown in `phpinfo()` per dir but never active? --- ## #57615 — Stefan Esser — 2012-02-02T14:14:56+00:00 URL: https://externals.io/message/57610#57615 · In reply to: #57613 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. The only reason why Suhosin exists is because there will ALWAYS be bugs. And because that is a fact you must have safe guards in case something goes wrong. Suhosin/HPHP provides this safe guard for 8 years to the PHP community. Ideas like: I haven't seen much bugs lately so lets drop all the safe guards is like not paying for your life insurance anymore, because you haven't died too often recently. 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. 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. Regards, Stefan Esser --- ## #57616 — Stefan Esser — 2012-02-02T14:59:12+00:00 URL: https://externals.io/message/57610#57616 · In reply to: #57610 Ohh btw… > 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/ 1) You understand that Hardening-Patch is not Suhosin-Patch, do you? 2) Maybe you should also search for: Have Debian, then use a clean PHP not a broken Debian build Bug 3 -> is not a bug in Suhosin, it is the fact that the suhosin.executor.max_depth function was not set correctly. Reading the documentation helps: http://www.hardened-php.net/suhosin/configuration.html#suhosin.executor.max_depth Bug 4 -> the guy is actually writing inside the bug report that the problem occurs with and without Suhosin 5) You can just start PHP with the environment variable SUHOSIN_MM_USE_CANARY_PROTECTION=0 and can use valgrind. So basically all points you bring up are no issues. Regards, Stefan Esser --- ## #57618 — Pierre Joye — 2012-02-02T15:49:58+00:00 URL: https://externals.io/message/57610#57618 · In reply to: #57615 hi Stefan, > Hello Pierre, > > > […] > > 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 --- ## #57619 — jpauli — 2012-02-02T16:06:48+00:00 URL: https://externals.io/message/57610#57619 · In reply to: #57618 > hi Stefan, > > > > […] > 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. > > > […] > > Indeed, so it is for Suhosin as well. > > > […] > 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. > > […] > 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. > > > […] > PHP. > > […] > 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 > > -- > > > > 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 :) Julien.P --- ## #57620 — Stefan Esser — 2012-02-02T16:10:29+00:00 URL: https://externals.io/message/57610#57620 · In reply to: #57618 Hello Pierre, > 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. Sorry it makes no difference if a feature was introduced into PHP by taking code from Suhosin or from someone else. Fact is the feature existed before in Suhosin. * GLOBALS overwrite protection * max_file_uploads * max_input_vars * `crypt()` blowfish * max_input_nesting_level * Superglobals overwrite protection in `explode()`/import_request_vars() * safe unlink in Zend memory manager * http response splitting protection against \n * http response splitting protection against \r <--- broken attempt to support this in PHP 5.4 * and most probably many more that I do not know from the top of my head (this are already 9 features and Suhosin/HPHP exists since 2004 = 8 years). > 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 Suhosin/HPHP existed 3 years before I left the security team. So the creation of it had nothing todo with me leaving the team. > 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. The fact is the PHP developers NEVER saw other features they needed to implement and then some external people disclosed some PHP bug and as a result one of the Suhosin features were cloned. The thing is: I see no problem with the status quo - Suhosin exists and people can use it - it is like people can choose if they want ASLR, NX, Fortify Source on their system. I do not have the time or wish to convince the PHP developers to add some features that most probably after some time will be copied/clones/reimplemented anyway. The only problem I see is that some PHP developers negate the fact that Suhosin increases security of PHP (which was proven again and again for 8 years, why else clone features) and recommend people to stay away from it: This is malicious. And yes I like the Suhosin codebase separate, because if there is a bug I can smack the responsible person (myself) over the head bigtime. If Suhosin merges with PHP a lot of patches will go into the code and the work to keep track with every commit that touches some Suhosin feature will explode. Just look at security patches like this: http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997 Yes it is one of the features that is in Suhosin for a long time -> anyway that security fix is completely broken and noone cares about it. Regards, Stefan Esser --- ## #57621 — Pierre Joye — 2012-02-02T16:26:22+00:00 URL: https://externals.io/message/57610#57621 · In reply to: #57620 > Hello Pierre, > > > […] > > Sorry it makes no difference if a feature was introduced into PHP by taking code from Suhosin or from someone else. Fact is the feature existed before in Suhosin. I corrected your statement, in fact it makes no difference except that giving back to Caesar... > The thing is: I see no problem with the status quo - Suhosin exists and people can use it - it is like people can choose if they want ASLR, NX, Fortify Source on their system. I do see a problem and this problem is the reason why I do not think Suhosin is the right way. To me it creates more issues than it solves. I cannot count the amount of people I have met (or myself) having issues using Suhosin while not having them with a vanilla PHP. > I do not have the time or wish to convince the PHP developers to add some features that most probably after some time will be copied/clones/reimplemented anyway. But you have time to convince them and the distros to use the patch, there is something wrong here :) > The only problem I see is that some PHP developers negate the fact that Suhosin increases security of PHP (which was proven again and again for 8 years, why else clone features) and recommend people to stay away from it: This is malicious. You miss the point. And please, make yourself a favour, don't consider all PHP developers as being one single entity, it is not. The discussions you could have in the past and what other thinks today are two different things. In other words, move forward, stop to keep looking at the past. > And yes I like the Suhosin codebase separate, because if there is a bug I can smack the responsible person (myself) over the head bigtime. It is indeed easier for you to work with you alone. Now if I put that from our users base perspective, this argument is totally invalid. > If Suhosin merges with PHP a lot of patches will go into the code and the work to keep track with every commit that touches some Suhosin feature will explode. > Just look at security patches like this: > > http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997 > > Yes it is one of the features that is in Suhosin for a long time -> anyway that security fix is completely broken and noone cares about it. This is exactly where you should help php directly instead of doing what you do now to defend your patch. In the long run (or maybe even mid term), the Suhosin patch will disappear. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57622 — Derick Rethans — 2012-02-02T16:30:21+00:00 URL: https://externals.io/message/57610#57622 · In reply to: #57620 > Sorry it makes no difference if a feature was introduced into PHP by > taking code from Suhosin or from someone else. Fact is the feature > existed before in Suhosin. > > * GLOBALS overwrite protection > * max_file_uploads > * max_input_vars > * `crypt()` blowfish > * max_input_nesting_level > * Superglobals overwrite protection in `explode()`/import_request_vars() > * safe unlink in Zend memory manager > * http response splitting protection against \n > * http response splitting protection against \r <--- broken attempt to support this in PHP 5.4 What is broken, and where is a possible patch? > * and most probably many more that I do not know from the top of my > head (this are already 9 features and Suhosin/HPHP exists since 2004 = > 8 years). Lots of stuff in PHP was also "stolen" from Xdebug, but I am not whining about that as the goal is (and has always been) to make PHP better. > http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/main/SAPI.c?r1=317225&r2=318997 > > Yes it is one of the features that is in Suhosin for a long time -> > anyway that security fix is completely broken and noone cares about > it. I'm sure we'd be more than happy to hear why it's broken and hear about possible suggested fixes. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #57623 — Stefan Esser — 2012-02-02T16:35:08+00:00 URL: https://externals.io/message/57610#57623 · In reply to: #57622 Hello Derick, > > […] > > Lots of stuff in PHP was also "stolen" from Xdebug, but I am not whining > about that as the goal is (and has always been) to make PHP better. I am not whining of something being stolen I trying to demonstrate that a lot of the features noone ever saw a need for in PHP have been cloned. PHP devs repeatedly tell that Suhosin brings no additional value, while they clone and clone every time they are hit by a nasty bug. > > […] > > I'm sure we'd be more than happy to hear why it's broken and hear about > possible suggested fixes. The purpose of the code is to detect all occurences of \r or \n not followed by whitespace and error out. It is obviously doing something else. Regards, Stefan --- ## #57624 — Stefan Esser — 2012-02-02T16:40:09+00:00 URL: https://externals.io/message/57610#57624 · In reply to: #57621 Hello Pierre, > This is exactly where you should help php directly instead of doing > what you do now to defend your patch. In the long run (or maybe even > mid term), the Suhosin patch will disappear. I seriously doubt that. The PHP developers will never ever merge all features into the PHP core. And therefore Suhosin will continue to add additonal value. Especially since the next Suhosin-Patch for PHP 5.4.0 will already have new and more mitigations. Regards, Stefan --- ## #57625 — Stas Malyshev — 2012-02-02T17:37:14+00:00 URL: https://externals.io/message/57610#57625 · In reply to: #57614 Hi! > yes, but suhosin-extension and hardening patch exists since many years > > the question from a normal user: > why are these things not included in the core? Because some of these things slow down the code and thus may not be beneficial to the most users. > especially the option to disable function by directory while > "disable_functions" is stupidity shown in `phpinfo()` per dir > but never active? With this feature this may not be a problem, however (I don't know, didn't look into the actual code). But somebody has to propose it for inclusion into the core and lead it - i.e. answer questions, participate in the discussion, change/maintain the patches, etc. If this happens, I don't see why some of the features can't be brought into code. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #57626 — Pierre Joye — 2012-02-02T17:41:53+00:00 URL: https://externals.io/message/57610#57626 · In reply to: #57624 hi Stefan, You do not want that to happen, that's different than we, as a project, not willing to see what could be done and help you or anyone to get that done. The RFC process also makes that possible in a very easy and open way. > Hello Pierre, > > > […] > > > I seriously doubt that. The PHP developers will never ever merge all features into the PHP core. And therefore Suhosin will continue to add additonal value. > Especially since the next Suhosin-Patch for PHP 5.4.0 will already have new and more mitigations. > > > Regards, > Stefan -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57627 — Reindl Harald — 2012-02-02T17:42:26+00:00 URL: https://externals.io/message/57610#57627 · In reply to: #57625 Am 02.02.2012 18:37, schrieb Stas Malyshev: > > […] > > Because some of these things slow down the code we are using suhosin patch and extension since years on 5 VMware-Guests on the same host for 500 domains and even running one of them a site with many hundret active sessions was not a single performance problem without bytecode-cache you have much more problems > thus may not be beneficial to the most users security is not beneficial to the most users? security is THE benefit for ALL users, especially in days where many are running crap-code like Joomla/Wordpress with all sorts of plugins throwing millions of warning if you run with `E_ALL` and E_STRCIT --- ## #57628 — Stas Malyshev — 2012-02-02T17:59:07+00:00 URL: https://externals.io/message/57610#57628 · In reply to: #57615 Hi! > I know that for many years you have not understood the idea behind > Suhosin, the concept of exploit mitigations. I think we have a difference of approaches here, and it is well known. There's more or less a consensus among PHP dev that to introduce a feature, especially with high user performance cost and other risks, into PHP its necessity to the user needs to be proven and outweigh the problems it causes. You seem to advocate the approach in which performance and convenience can and should be sacrificed to security. It is a matter of opinion, and each one has its own validity. We probably would have for now to agree to disagree here. That said, I personally would be happy to see more participation from you - including and especially contributing and maintaining parts of Suhosin patch that do not have high costs and user issues associated with them and are not controversial - I think it would benefit PHP a lot. Of course, it's your decision, but I think that would be better both for PHP security and PHP users which have little interest in what belongs where and why, but right now the only person who can maintain and support any line of code in Suhosin is you, which is not always helpful to the users. > 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. There's no "hundred PHP committers" except in theory. In practice, number of people regularly committing to relevant part of the core is probably less then 10. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #57629 — Stas Malyshev — 2012-02-02T18:02:15+00:00 URL: https://externals.io/message/57610#57629 · In reply to: #57627 Hi! > with many hundret active sessions was not a > single performance problem I'm not sure I understand what you are talking about here. Performance is a scale, not a trigger. If you lose 10% (totally invented number as an example) that doesn't mean you have 10 of "performance problems", it means you sites run 10% slower, you need 10% more servers, etc. > without bytecode-cache you have much more problems What bytecode cache has to do with it? Sounds like a non-sequitur. > > > […] > > security is not beneficial to the most users? Please don't do that. I never said that security is not beneficial, and as you quoted me you know that and you know that "not beneficial" related to the performance hit the mitigation measures cost. > security is THE benefit for ALL users, especially in days where many > are running crap-code like Joomla/Wordpress with all sorts of plugins > throwing millions of warning if you run with `E_ALL` and E_STRCIT What the quality of the code of Joomla has to do with anything? Suhosin patches would not fix Joomla and most of the issues it helps with are totally unrelated to any user code at all. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #57630 — Reindl Harald — 2012-02-02T18:11:54+00:00 URL: https://externals.io/message/57610#57630 · In reply to: #57629 Am 02.02.2012 19:02, schrieb Stas Malyshev: > Hi! > > > […] > > I'm not sure I understand what you are talking about here. Performance is a scale, > not a trigger. If you lose 10% (totally invented number as an example) that doesn't > mean you have 10 of "performance problems", it means you sites run 10% slower, you > need 10% more servers, etc. as long the cms generates a whole dynamic page from before the first library include until the genereated page is ready in 0.014 seconds while you have some hundret active users including an ajax check and having suhosin enabled at this time where is a SINGLE reason to degrade security by default? for people running on a 10 year old machine fast but unsecure? what the hell - on a public sever security is the first and most important topic and LONG after that performance is one > > […] > What bytecode cache has to do with it? Sounds like a non-sequitur. overall performance i look at the performance of the whole machine and not a single part because the single part does not matter if it leads to successful exploits at last and your whole server is down and owned - what benefit had you after such things happened because it was a little faster? > > […] > > Please don't do that. I never said that security is not beneficial, and as you quoted > me you know that and you know that "not beneficial" related to the performance hit > the mitigation measures cost. performance comes in the priority LONG after security so this is nothing to discuss > > […] > > What the quality of the code of Joomla has to do with anything? Suhosin patches > would not fix Joomla and most of the issues it helps with are totally unrelated > to any user code at all. if code is blowing out millions of warnings it is poorly written code and poorly written code is ALWAYS a security problem look at the logs how many bad inputs suhosin is dropping mostly of them are attacks if someone attacks your machine EVERY piece increasing security will make the rsik of a successful intrusion lower, and yes EVERY server is attacked, every day and every night as long it has a public IP --- ## #57631 — keisial@gmail.com — 2012-02-02T18:35:03+00:00 URL: https://externals.io/message/57610#57631 · In reply to: #57615 Stefan Esser wrote: > 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. That's not a justification to keep it as a patch. Safe guards could prefectly be skipped by a commit which changed near code, reestructures the function or creates a different path, *even if the patch still applies*. So you would still need to check for all kind of unexpected changes anyway. If it were in core, at least anyone changing the related code would realise that it's there, and could take that into account for not breaking it. If it's maintained by someone else as a patch, that simply won't happen. --- ## #57632 — Tomas Kuliavas — 2012-02-02T18:42:32+00:00 URL: https://externals.io/message/57610#57632 · In reply to: #57627 2012.02.02 19:42 Reindl Harald rašė: > security is THE benefit for ALL users, especially in days where many > are running crap-code like Joomla/Wordpress with all sorts of plugins > throwing millions of warning if you run with `E_ALL` and E_STRCIT `E_STRICT` throws notices on properly written code. It contains coding recommendations that are not compatible with older PHP and code has to choose between losing backwards compatibility or suppressing those notices. In some PHP versions suppressing of `E_STRICT` will also suppress fatal errors caused by buggy interpreter. Latest PHP with deprecation notices in `E_ALL` also throws lots of shit which does not apply to version you are running. -- Tomas --- ## #57633 — Pierre Joye — 2012-02-02T19:00:23+00:00 URL: https://externals.io/message/57610#57633 · In reply to: #57632 This is off topic, can we stay on focus please? (and disable these levels if you don't want to see them in your logs) On Thu, Feb 2, 2012 at 7:42 PM, Tomas Kuliavas wrote: > 2012.02.02 19:42 Reindl Harald rašė: > > […] > > `E_STRICT` throws notices on properly written code. It contains coding > recommendations that are not compatible with older PHP and code has to > choose between losing backwards compatibility or suppressing those > notices. In some PHP versions suppressing of `E_STRICT` will also suppress > fatal errors caused by buggy interpreter. > > Latest PHP with deprecation notices in `E_ALL` also throws lots of shit > which does not apply to version you are running. > > -- > Tomas > > > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #57634 — Reindl Harald — 2012-02-02T19:44:14+00:00 URL: https://externals.io/message/57610#57634 · In reply to: #57632 Am 02.02.2012 19:42, schrieb Tomas Kuliavas: > 2012.02.02 19:42 Reindl Harald rašė: > > […] > > `E_STRICT` throws notices on properly written code. It contains coding > recommendations that are not compatible with older PHP and code has to > choose between losing backwards compatibility or suppressing those > notices. In some PHP versions suppressing of `E_STRICT` will also suppress > fatal errors caused by buggy interpreter. > > Latest PHP with deprecation notices in `E_ALL` also throws lots of shit > which does not apply to version you are running. well, someone may like this but there is no single reason that `E_ALL` or `E_WARNING` throws any line i be there, since 8 years now running it in prorudction for over 500 domains with self developed code AND a cron-job which will mail me ANY warning in the errorlog every 30 minutes so nobdy out there can tell me it is impossible to write clean code --- ## #57635 — Thomas Goirand — 2012-02-02T20:11:36+00:00 URL: https://externals.io/message/57610#57635 · In reply to: #57628 > You seem to advocate the approach in which > performance and convenience can and should be sacrificed to security. > It is a matter of opinion Something I don't get here. If there's this issue, and different tastes, why can't a build flag be used, so that you can choose security or speed depending on your needs? If you do some: #ifdef ENABLE_SLOWER_SUHOSIN_SECURITY in the controversial parts, then I don't see how this would be of trouble for anyone to have Suhosin included in upstream PHP. Cheers, Thomas Goirand (zigo) --- ## #57637 — Christoph Anton Mitterer — 2012-02-03T00:28:22+00:00 URL: https://externals.io/message/57610#57637 · In reply to: #57610 Hey. First, thanks Ondřej, for bringing this to a wider audience :) > 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. > > 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. I guess these three could be solved by my suggestion of having separate packages with and without the suhosin core patched applied. In case of (1), people can just choose. This is just what Stas Malyshev talked about. Some people may depend on speed/memory... some absolutely not (just take my little DAViCal server which is responsible for #657698 and this discussion ;) ). In case of (2), one can ask them to reproduce it first with the non-suhosin package. > 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. I don't know any details here, but as long as his patched work well on the vanilla source,... it shouldn't be a major issue for Debian, right? I agree with Stefan, that having such guards is a good thing. This is to some extent why things like grsceurity, PaX, and similar exist. There always was need for them,.. and I guess there allways will be. Just saying "there were only few security holes recently" is not an argument. An argument would be "most/all features of suhosin are now integrated or handled similarly in PHP anyway". I think that also his argument of the advantage of having such a patch external is not to stupid,... of course it makes problems in other corners. Btw: Stefan, while I understand that you may feel offended that suhosin it dropped/attacked/criticised, I guess it doesn't help that you use unfriendly words. And the same applies to those who did vice versa (to Stefan). > For example, Debian could immediately become a much more secure OS > by enabling SELinux in enforcing mode on all Debian systems. > The reason why we don't do this is that currently that tradeoff > doesn't make sense; too much other stuff doesn't work, too much > other effort is required, and we're not in a position to enforce > that technology, even if it would increase security. I don't want to open a discussion about whether SELinux or some other framwork is THE answer ;-) but I always had the impression that the blocker here was rather that there is (which is also a good think) no single dictator in Debian who can really say: All maintainers, listen up, go an support SELinux in your packages. (Which RedHat can do). Apart from that, I fully agree with your arguments. The reasons why I've opened #657698 was just, because I though it could be possible for the PHP maintainers to reduce their burden, by just offering both, packages with suhosin and without. If there are bugs in the with suhosin version, they can either redirect people to upstream, or the no suhosin version or even (if time is available) try to help. I have however still not understood, whether one would need to compile the extensions for both versions, Stefan?! > SE Linux is supported in critical packages including the kernel, > sysvinit, and cron. So any user who wants to use it can just > install the SE Linux specific packages and rely on the built-in > support for SE Linux in important base packages. > This compares to the PHP/Suhosin situation where users who want that > have no option other than to download the source and the Suhosin > patch and build their own packages. Phew,.. but is it really a good idea to let this be done by innocent end-users?! I mean this IS just why the critical packages support SELinux and don't require the the users to do it themselves. Analogously, this applies to the PHP core packages, IMHO. > Something I don't get here. If there's this issue, and > different tastes, why can't a build flag be used, so > that you can choose security or speed depending on your > needs? If you do some: > > #ifdef ENABLE_SLOWER_SUHOSIN_SECURITY > > in the controversial parts, then I don't see how this > would be of trouble for anyone to have Suhosin included > in upstream PHP. Absolutely +1 ;-) But this wouldn't solve our discussion here... the question would still be open, whether Debian sets this flag or not, or whether it makes two binary packages. Cheers, Chris. --- Next page: https://externals.io/message/57610.md?page=2