# Include XDebug and Suhosin Patch in Core for 5.5 - Thread: https://externals.io/message/66354 - Original archive: https://news-web.php.net/php.internals/66354 - Started by Anthony Ferrara on 2013-02-28T20:00:55+00:00 - Messages: 13 - 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 --- ## #66354 — Anthony Ferrara — 2013-02-28T20:00:55+00:00 URL: https://externals.io/message/66354#66354 Hey all, Based off of the recent discussion around pulling in ZO+ into core, I've come to the conclusion that we should also pull in XDebug and Suhosin into core at the same time. 1. It has integration issues with ZO+ in that it has to be included in a specific order (specifically around ini declarations). If it was included into core, this could be accounted for allowing for more robust behavior. 2. Both to be maintained for each new language feature as well as opcode-caches. This will have the same benefit as integrating ZO+, as it can be maintained inline with the engine. 3. Both stand as a barrier to adoption as many will not run PHP in development without XDebug, and they won't run it in production without the Suhosin patch. Since both of these are vital to PHP's uptake and adoption of new versions, I feel it's important to delay 5.5 until we can get both in. I can draft up the RFC if necessary... Anthony --- ## #66357 — Stas Malyshev — 2013-02-28T20:13:04+00:00 URL: https://externals.io/message/66354#66357 · In reply to: #66354 Hi! > Based off of the recent discussion around pulling in ZO+ into core, I've > come to the conclusion that we should also pull in XDebug and Suhosin into > core at the same time. Suhosin has multiple BC-incompatible and performance-problematic changes and limits and the author refused many times to work with PHP team. I'm not sure how we could pull extension that the author of it isn't interested in working with PHP group. > 1. It has integration issues with ZO+ in that it has to be included in a > specific order (specifically around ini declarations). If it was included > into core, this could be accounted for allowing for more robust behavior. I'm not sure what you mean about ini declarations, could you expand on this or refer me to the place where it is explained? > 2. Both to be maintained for each new language feature as well as > opcode-caches. This will have the same benefit as integrating ZO+, as it > can be maintained inline with the engine. I'm not sure how it's different than any other extension. If API changes, they need to change for every version. Also, are you sure either of the maintainers actually wants to be part of PHP release cycle? At least for Suhosin we know it's actually not the case. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #66359 — Michael Wallner — 2013-02-28T20:17:34+00:00 URL: https://externals.io/message/66354#66359 · In reply to: #66354 [...] Sorry, but I hope you are in some funny sort of mood... Mike --- ## #66363 — Derick Rethans — 2013-02-28T20:39:34+00:00 URL: https://externals.io/message/66354#66363 · In reply to: #66354 > Based off of the recent discussion around pulling in ZO+ into core, > I've come to the conclusion that we should also pull in XDebug and > Suhosin into core at the same time. Suhosin has a large performance impact (even the normal patch, without turning on anything). > 3. Both stand as a barrier to adoption as many will not run PHP in > development without XDebug What do you mean? derick@whisky:~/dev/php/xdebug-xdebug $ TEST_PHP_EXECUTABLE=`which php` php -dxdebug.auto_trace=0 run-tests.php ===================================================================== PHP : /usr/local/php/5.5dev/bin/php `PHP_SAPI` : cli `PHP_VERSION` : 5.5.0-dev ZEND_VERSION: 2.5.0-dev `PHP_OS` : Linux - Linux whisky 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 … Number of tests : 234 221 Tests skipped : 13 ( 5.6%) -------- Tests warned : 0 ( 0.0%) ( 0.0%) Tests failed : 0 ( 0.0%) ( 0.0%) Expected fail : 1 ( 0.4%) ( 0.5%) Tests passed : 220 ( 94.0%) ( 99.5%) --------------------------------------------------------------------- Time taken : 16 seconds ===================================================================== cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine --- ## #66366 — Anthony Ferrara — 2013-02-28T21:23:00+00:00 URL: https://externals.io/message/66354#66366 · In reply to: #66363 Derick: > > > > […] > > Suhosin has a large performance impact (even the normal patch, without > turning on anything). > > > […] > > What do you mean? > > derick@whisky:~/dev/php/xdebug-xdebug $ TEST_PHP_EXECUTABLE=`which php` > php -dxdebug.auto_trace=0 run-tests.php > > ===================================================================== > PHP : /usr/local/php/5.5dev/bin/php > `PHP_SAPI` : cli > `PHP_VERSION` : 5.5.0-dev > ZEND_VERSION: 2.5.0-dev > `PHP_OS` : Linux - Linux whisky 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 > x86_64 > > … > > Number of tests : 234 221 > Tests skipped : 13 ( 5.6%) -------- > Tests warned : 0 ( 0.0%) ( 0.0%) > Tests failed : 0 ( 0.0%) ( 0.0%) > Expected fail : 1 ( 0.4%) ( 0.5%) > Tests passed : 220 ( 94.0%) ( 99.5%) > --------------------------------------------------------------------- > Time taken : 16 seconds > ===================================================================== > It appears that xdebug is borking generator exception handling. Without xdebug the following two tests pass, but with it they fail: Generator::throw() where the exception is caught in the generator [Zend/tests/generators/throw_caught.phpt] Generator::throw() where the generator throws a different exception [Zend/tests/generators/throw_rethrow.phpt] And I'm not saying that you're not doing a good job keeping it up. I'm just saying that it needs to be kept up, so why not put it right in core where it can be maintained together. The only difference between this and ZO+ in this case is... Well, there really isn't one. Both opcode caches and debuggers are WIDELY installed. Both are blockers for upgrading. Both are supported well (now that ZO+ is open sourced that is). So the drive and justification for pulling one into core should completely fit the other... --- ## #66371 — Derick Rethans — 2013-02-28T21:43:39+00:00 URL: https://externals.io/message/66354#66371 · In reply to: #66366 > It appears that xdebug is borking generator exception handling. Without > xdebug the following two tests pass, but with it they fail: > > Generator::throw() where the exception is caught in the generator > [Zend/tests/generators/throw_caught.phpt] > Generator::throw() where the generator throws a different exception > [Zend/tests/generators/throw_rethrow.phpt] I guess that's because something hijacks the throw exception handler, it's the samething with SOAP. This should be addressed so that there is a chain/set of handlers instead. > And I'm not saying that you're not doing a good job keeping it up. I'm > just saying that it needs to be kept up, so why not put it right in > core where it can be maintained together. The only difference between > this and ZO+ in this case is... Well, there really isn't one. Both > opcode caches and debuggers are WIDELY installed. Both are blockers > for upgrading. Both are supported well (now that ZO+ is open sourced > that is). So the drive and justification for pulling one into core > should completely fit the other... I don't want it. cheers, Derick --- ## #66375 — Adam Jon Richardson — 2013-02-28T22:00:39+00:00 URL: https://externals.io/message/66354#66375 · In reply to: #66354 > 1. It has integration issues with ZO+ in that it has to be included in a > specific order (specifically around ini declarations). If it was included > into core, this could be accounted for allowing for more robust behavior. I don't use Suhoshin, nor do I want to (not that it is bad, I just don't want the performance hit.) Additionally, I like to set up a development environment with XDebug, and I like to leave XDebug out of my production environment. > 2. Both to be maintained for each new language feature as well as > opcode-caches. This will have the same benefit as integrating ZO+, as it > can be maintained inline with the engine. Derrick is doing a great job keeping XDebug up-to-date, so why does this need to change. In contrast, APC was having a very difficult time keeping up. > 3. Both stand as a barrier to adoption as many will not run PHP in > development without XDebug, and they won't run it in production without the > Suhosin patch. Many won't run WITH Sohosin in production. In terms of XDebug and opcode caches, I really do believe there is a big difference between the two in terms of the severity of bugs. A bug in XDebug is not as critical to me, as I can live with and work around XDebug issues (what few I've encountered) because I experience these in dev environments. However, an opcode cache is a production environment feature, which makes these bugs much more severe in nature. Adam --- ## #66387 — David Muir — 2013-03-01T10:39:16+00:00 URL: https://externals.io/message/66354#66387 · In reply to: #66354 > Hey all, > > Based off of the recent discussion around pulling in ZO+ into core, I've > come to the conclusion that we should also pull in XDebug and Suhosin into > core at the same time. > > 1. It has integration issues with ZO+ in that it has to be included in a > specific order (specifically around ini declarations). If it was included > into core, this could be accounted for allowing for more robust behavior. > > 2. Both to be maintained for each new language feature as well as > opcode-caches. This will have the same benefit as integrating ZO+, as it > can be maintained inline with the engine. > > 3. Both stand as a barrier to adoption as many will not run PHP in > development without XDebug, and they won't run it in production without the > Suhosin patch. > > Since both of these are vital to PHP's uptake and adoption of new versions, > I feel it's important to delay 5.5 until we can get both in. I can draft up > the RFC if necessary... > > Anthony Nice :-P Seriously though, what's the deal with the Suhosin patch? I use it because it's included by default on Ubuntu... Didn't know about the huge performance impact. Their website seems to imply that PHP has security holes that have never been patched, and are only closed by using Suhosin. I find that hard to believe. Is PHP really *that* vulnerable without it? The site (http://www.hardened-php.net/suhosin/) is somewhat light on details. Cheers, David --- ## #66388 — Julien Pauli — 2013-03-01T11:01:26+00:00 URL: https://externals.io/message/66354#66388 · In reply to: #66387 > > > > > […] > into > > […] > the > > […] > versions, > > […] > up > > […] > > > Nice :-P > > Seriously though, what's the deal with the Suhosin patch? I use it because > it's included by default on Ubuntu... Didn't know about the huge > performance impact. Their website seems to imply that PHP has security > holes that have never been patched, and are only closed by using Suhosin. I > find that hard to believe. Is PHP really *that* vulnerable without it? The > site (http://www.hardened-php.net/suhosin/) is somewhat light on details. > Any computer system is vulnerable as far as you press the start button and plug in the network cable ;-) Julien --- ## #66389 — Julien Pauli — 2013-03-01T11:02:40+00:00 URL: https://externals.io/message/66354#66389 · In reply to: #66357 On Thu, Feb 28, 2013 at 9:13 PM, Stas Malyshev wrote: > Hi! > > > […] > into > > […] > > Suhosin has multiple BC-incompatible and performance-problematic changes > and limits and the author refused many times to work with PHP team. I'm > not sure how we could pull extension that the author of it isn't > interested in working with PHP group. > +1 > > > […] > > I'm not sure what you mean about ini declarations, could you expand on > this or refer me to the place where it is explained? > I guess the ini declaration order and then the order the modules get loaded in the engine. Julien --- ## #66392 — Kalle Sommer Nielsen — 2013-03-01T11:49:02+00:00 URL: https://externals.io/message/66354#66392 · In reply to: #66389 Hi 2013/3/1 Julien Pauli : > I guess the ini declaration order and then the order the modules get loaded > in the engine. We could also look at implementing a module-load-order internally in the zend_module struct, as in some extensions like EXIF relies on mbstring, while the ZEND_MODULE_DEP()s works fine for checking for mbstring, it does not work if mbstring is loaded after. So what I'm saying is that mbstring have a higher load order, meaning even though we have this in php.ini[1], PHP will load mbstring first because it has the lowest value (requiring it to start first), or giving exif a higher than 'normal' value (causing it to load after, as it is after all, exif that depends on mbstring, not the other way around). The same thing can be done with engine level extensions (zend_extension), where it probably would make more sense than for 90% of all 'php' extensions. [1]: extension=php_exif.dll extension=php_mbstring.dll -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #66393 — Julien Pauli — 2013-03-01T13:28:38+00:00 URL: https://externals.io/message/66354#66393 · In reply to: #66392 > Hi > > 2013/3/1 Julien Pauli : > > […] > loaded > > […] > > We could also look at implementing a module-load-order internally in > the zend_module struct, as in some extensions like EXIF relies on > mbstring, while the ZEND_MODULE_DEP()s works fine for checking for > mbstring, it does not work if mbstring is loaded after. So what I'm > saying is that mbstring have a higher load order, meaning even though > we have this in php.ini[1], PHP will load mbstring first because it > has the lowest value (requiring it to start first), or giving exif a > higher than 'normal' value (causing it to load after, as it is after > all, exif that depends on mbstring, not the other way around). > > The same thing can be done with engine level extensions > (zend_extension), where it probably would make more sense than for 90% > of all 'php' extensions. > > [1]: > extension=php_exif.dll > extension=php_mbstring.dll > +1 , Some time ago when I first designed my first extensions studying the Zend extension loading mechanism I thought about such a system and was surprised not to find one into the engine. It shouldn't be too hard to develop, except if you start thinking about versions dependencies of the modules as well. In the same pipe, I was thinking at some dlunload() function which would enable unoloading modules at runtime, but that's another task, not very trivial though. Julien > > > > -- > regards, > > Kalle Sommer Nielsen > kalle@php.net --- ## #66394 — Raymond Irving — 2013-03-01T15:08:29+00:00 URL: https://externals.io/message/66354#66394 · In reply to: #66393 I agree with adding XDebug to core distribution but it must be disabled by default. > On Fri, Mar 1, 2013 at 12:49 PM, Kalle Sommer Nielsen > wrote: > > > […] > > +1 , Some time ago when I first designed my first extensions studying the > Zend extension loading mechanism I thought about such a system and was > surprised not to find one into the engine. > It shouldn't be too hard to develop, except if you start thinking about > versions dependencies of the modules as well. > > In the same pipe, I was thinking at some dlunload() function which would > enable unoloading modules at runtime, but that's another task, not very > trivial though. > > Julien > > > […]