[PHP-DEV] How about make php php-cgi php-fpm to use a common shared library.
This is my ugly patch for this. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Address feature request #38917 for native SPKAC (HTML5 keygen element) support: ext/openssl/openssl.c ext/openssl/php_openssl.h ext/openssl/tests/openssl_spki_
On Fri, May 10, 2013 at 9:40 PM, Stas Malyshev wrote: > Hi! > >>> Any chance of getting this into PHP 5.5? This patch has been waiting >>> around since 2006 ... >> >> I had to say no, we are in RC now, no new feature. > > I'd say 5.5.0 probably not, but see no problem with 5.5.1 - adding new > self-contained functions, which is what it seems to be doing, was long > OK for stable versions. > > I'd probably even be fine with getting it into 5.4, it looks > self-contained enough. I'd to disagree. Besides the lack of testing (openssl is stable, or do we begin to say feature a is not and feature b is beta but everything else is stable?), the nightmare about what is available in which version is really not what we should do. php-next will be in a year, openssl can be released in pecl as well. There are many requests supporting this idea, incl. from <5.5 users, incl. 5.3. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 and APC user cache upgrade path
On 05/09/2013 05:02 AM, Pierre Schmitz wrote: Hi, I am testing PHP 5.5 atm and how we can package it for Arch Linux and provide an upgrade path for users. The RC1 looks pretty solid so far. As the new opcache does not provide a user cache to store custom variables, I would be glad if you could clarify what the best migration from 5.4 would be. * Is APC basically dead and wont support PHP 5.5? From the lack of APC activity and from comments Rasmus has made in the bugs (e.g. [1]) this is a safe assumption. * Should APC users switch to opcache and APCu? (with APCu replacing the APC package) OPcache is definitely the opcode cache solution for PHP 5.5 For user data caches, there are a number of alternatives, as you noted. During this initial transition phase it isn't clear what the directions of each solution will be. It isn't clear that there will be one dominant solution. I'll leave it to Laruence and Joe to state their cases for world domination of YAC and APCu, respectively. Chris [1] https://bugs.php.net/bug.php?id=64625 For PHP application developers: * Regarding APCu: it provides the old PHP interface function as well as their own apcu_* functions. They are aliases right now. Should application developers think about switching to the apcu_-API as new features will be available only here? Bonus question: * Right now very similar functionality is provided by APCu, XCache, WinCache, YAC etc.. Are there plans to include such functionality inside PHP in future to make application developers life a little easier? At least a common API would be great. There were several bugs in applications as these modules behave a little different regarding return values etc.. Greetings, Pierre -- christopher.jo...@oracle.com http://twitter.com/ghrd Newly updated, free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Address feature request #38917 for native SPKAC (HTML5 keygen element) support: ext/openssl/openssl.c ext/openssl/php_openssl.h ext/openssl/tests/openssl_spki_
Hi! >> Any chance of getting this into PHP 5.5? This patch has been waiting >> around since 2006 ... > > I had to say no, we are in RC now, no new feature. I'd say 5.5.0 probably not, but see no problem with 5.5.1 - adding new self-contained functions, which is what it seems to be doing, was long OK for stable versions. I'd probably even be fine with getting it into 5.4, it looks self-contained enough. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] No-feedback cleanup?
On Fri, May 10, 2013 at 3:39 PM, Ferenc Kovacs wrote: > > > > On Mon, Feb 18, 2013 at 1:38 AM, Ferenc Kovacs wrote: > >> >> >> >> On Sun, Feb 17, 2013 at 6:31 PM, Ferenc Kovacs wrote: >> >>> >>> 2013.02.17. 11:36, "Stas Malyshev" ezt írta: >>> >>> > >>> > Hi! >>> > >>> > I remember we used to have a script that goes over bugs DB and closes >>> > bugs that are in "Feedback" status for too long. Does it still happen? >>> > Because we have bugs that are in feedback status for a long time: like >>> > this one: https://bugs.php.net/bug.php?id=52961 - in Feedback for 2+ >>> > years. If the script is not run for some reason, I think we should >>> > restore it. >>> > -- >>> > Stanislav Malyshev, Software Architect >>> > SugarCRM: http://www.sugarcrm.com/ >>> > (408)454-6900 ext. 227 >>> > >>> > -- >>> > PHP Internals - PHP Runtime Development Mailing List >>> > To unsubscribe, visit: http://www.php.net/unsub.php >>> > >>> >>> I found the script (scripts/cron/no-feedback or something like that) but >>> I have to figure out how it should be called (maybe via curl/wget) because >>> it expects a post variable and stuff and execution from cli errors out. >>> if somebody remembers the setup feel free to beat me with the >>> restoration. >>> >> >> I've fixed up that script, executed so all bugs should be in the No >> feedback status and added it to the crontab on the bugsweb machine. >> >> -- >> Ferenc Kovács >> @Tyr43l - http://tyrael.hu >> > > and it seems that somebody commented out the script in the crontab on feb > 17 so it hasn't run since. > could the one who did that ellaborate why did was it needed and it is > still the case or can I re-activate it again? > > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > on a related not /local/systems/update-systems is also commented out in the crontab, and it seems that it hasn't run since marc 8. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] No-feedback cleanup?
On Mon, Feb 18, 2013 at 1:38 AM, Ferenc Kovacs wrote: > > > > On Sun, Feb 17, 2013 at 6:31 PM, Ferenc Kovacs wrote: > >> >> 2013.02.17. 11:36, "Stas Malyshev" ezt írta: >> >> > >> > Hi! >> > >> > I remember we used to have a script that goes over bugs DB and closes >> > bugs that are in "Feedback" status for too long. Does it still happen? >> > Because we have bugs that are in feedback status for a long time: like >> > this one: https://bugs.php.net/bug.php?id=52961 - in Feedback for 2+ >> > years. If the script is not run for some reason, I think we should >> > restore it. >> > -- >> > Stanislav Malyshev, Software Architect >> > SugarCRM: http://www.sugarcrm.com/ >> > (408)454-6900 ext. 227 >> > >> > -- >> > PHP Internals - PHP Runtime Development Mailing List >> > To unsubscribe, visit: http://www.php.net/unsub.php >> > >> >> I found the script (scripts/cron/no-feedback or something like that) but >> I have to figure out how it should be called (maybe via curl/wget) because >> it expects a post variable and stuff and execution from cli errors out. >> if somebody remembers the setup feel free to beat me with the restoration. >> > > I've fixed up that script, executed so all bugs should be in the No > feedback status and added it to the crontab on the bugsweb machine. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu > and it seems that somebody commented out the script in the crontab on feb 17 so it hasn't run since. could the one who did that ellaborate why did was it needed and it is still the case or can I re-activate it again? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] Re: PHP 5.5 and APC user cache upgrade path
On 05/09/2013 01:02 PM, Pierre Schmitz wrote: Hi, I am testing PHP 5.5 atm and how we can package it for Arch Linux and provide an upgrade path for users. The RC1 looks pretty solid so far. As the new opcache does not provide a user cache to store custom variables, I would be glad if you could clarify what the best migration from 5.4 would be. * Is APC basically dead and wont support PHP 5.5? * Should APC users switch to opcache and APCu? (with APCu replacing the APC package) For PHP application developers: * Regarding APCu: it provides the old PHP interface function as well as their own apcu_* functions. They are aliases right now. Should application developers think about switching to the apcu_-API as new features will be available only here? Bonus question: * Right now very similar functionality is provided by APCu, XCache, WinCache, YAC etc.. Are there plans to include such functionality inside PHP in future to make application developers life a little easier? At least a common API would be great. There were several bugs in applications as these modules behave a little different regarding return values etc.. Greetings, Pierre Working backwards: I personally don't see a reason for user caches to be in the core, not least of all there are multiple solutions, all suitable and some still maintained. The reason I think it's not really a core feature is that caching of user variables is something that must be explicit in an application, whereas opcode caching and the optimization that opcache performs should be a standard part of the compilation stage of execution, so fits better in the core. There's no merit to the argument that opcache and APC/YAC/whatever could share shm logic: the kind of implementation that APC(u) and opcache need are very different, right now they both have a suitable allocator. Furthermore, YAC implements (a very clever) completely different way of allocating shared memory, which should be tested on it's own merit in the real world before I consider implementing it's allocator in APCu. By default, APCu builds in an APC-compatible manner, emulating the old functions for APC, no change should be required to run legacy code relying on APC. New features, if they are written, will not be included in the APCu codebase, instead, APCu exposes all of it's API to other extensions, which allows any future features to be written and maintained completely separately, which I think to be a better solution as APC is in such heavy use. Very few people are able to helpfully maintain an opcode cache, the idea of including opcache in the core, or one of the ideas/benefits, is that everyone able can concentrate on one solution, implicitly APC will fall by the wayside where opcode caching is concerned. However, it is possible to run APC and opcache side by side by fiddling with ini settings, I can't really say if this is advisable or not, a possibility all the same. I think that's everything ... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Address feature request #38917 for native SPKAC (HTML5 keygen element) support: ext/openssl/openssl.c ext/openssl/php_openssl.h ext/openssl/tests/openssl_spki_
On Fri, May 10, 2013 at 1:01 PM, Sebastian Bergmann wrote: > Am 07.05.2013 00:36, schrieb Jason Gerfen: > > Commit:8f56ac8401ed1c3e00b8fba3fb8e5efb565180c4 > > Author:jas- Mon, 6 May 2013 > 16:36:06 -0600 > > Parents: da07e91c3a7e7bac2e380f24c59f70c1bcb3e7e4 > > Branches: master > > > > Link: > http://git.php.net/?p=php-src.git;a=commitdiff;h=8f56ac8401ed1c3e00b8fba3fb8e5efb565180c4 > > > > Log: > > Address feature request #38917 for native SPKAC (HTML5 keygen element) > support > > > > Bugs: > > https://bugs.php.net/38917 > > > > Changed paths: > > M ext/openssl/openssl.c > > M ext/openssl/php_openssl.h > > A ext/openssl/tests/openssl_spki_export.phpt > > A ext/openssl/tests/openssl_spki_export_challenge.phpt > > A ext/openssl/tests/openssl_spki_new.phpt > > A ext/openssl/tests/openssl_spki_verify.phpt > > Any chance of getting this into PHP 5.5? This patch has been waiting > around since 2006 ... > > are you sure? from the bug history it seems that the bug is from 2006 but the patch was submitted in 2011 december (still a while ago). either way, now that we are over the first RC and this is a security related feature which seems to nobody (other than the author) reviewed yet I think it would be better to wait for 5.6(or whatever will be next). -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Address feature request #38917 for native SPKAC (HTML5 keygen element) support: ext/openssl/openssl.c ext/openssl/php_openssl.h ext/openssl/tests/openssl_spki_
On Fri, May 10, 2013 at 1:01 PM, Sebastian Bergmann wrote: > Am 07.05.2013 00:36, schrieb Jason Gerfen: >> Commit:8f56ac8401ed1c3e00b8fba3fb8e5efb565180c4 >> Author:jas- Mon, 6 May 2013 16:36:06 >> -0600 >> Parents: da07e91c3a7e7bac2e380f24c59f70c1bcb3e7e4 >> Branches: master >> >> Link: >> http://git.php.net/?p=php-src.git;a=commitdiff;h=8f56ac8401ed1c3e00b8fba3fb8e5efb565180c4 >> >> Log: >> Address feature request #38917 for native SPKAC (HTML5 keygen element) >> support >> >> Bugs: >> https://bugs.php.net/38917 >> >> Changed paths: >> M ext/openssl/openssl.c >> M ext/openssl/php_openssl.h >> A ext/openssl/tests/openssl_spki_export.phpt >> A ext/openssl/tests/openssl_spki_export_challenge.phpt >> A ext/openssl/tests/openssl_spki_new.phpt >> A ext/openssl/tests/openssl_spki_verify.phpt > > Any chance of getting this into PHP 5.5? This patch has been waiting > around since 2006 ... I had to say no, we are in RC now, no new feature. However Wez and I always wanted to do pecl releases, to get more releases between PHP major versions and provide new features to older releases. That could help you as well. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: Address feature request #38917 for native SPKAC (HTML5 keygen element) support: ext/openssl/openssl.c ext/openssl/php_openssl.h ext/openssl/tests/openssl_spki_expo
Am 07.05.2013 00:36, schrieb Jason Gerfen: > Commit:8f56ac8401ed1c3e00b8fba3fb8e5efb565180c4 > Author:jas- Mon, 6 May 2013 16:36:06 > -0600 > Parents: da07e91c3a7e7bac2e380f24c59f70c1bcb3e7e4 > Branches: master > > Link: > http://git.php.net/?p=php-src.git;a=commitdiff;h=8f56ac8401ed1c3e00b8fba3fb8e5efb565180c4 > > Log: > Address feature request #38917 for native SPKAC (HTML5 keygen element) support > > Bugs: > https://bugs.php.net/38917 > > Changed paths: > M ext/openssl/openssl.c > M ext/openssl/php_openssl.h > A ext/openssl/tests/openssl_spki_export.phpt > A ext/openssl/tests/openssl_spki_export_challenge.phpt > A ext/openssl/tests/openssl_spki_new.phpt > A ext/openssl/tests/openssl_spki_verify.phpt Any chance of getting this into PHP 5.5? This patch has been waiting around since 2006 ... -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] exceptions during __toString()
On Fri, May 10, 2013 at 12:50 AM, Etienne Kneuss wrote:
> On Fri, May 10, 2013 at 12:00 AM, Rasmus Schultz >wrote:
>
> > I just ran into this issue again:
> >
> >
> >
> http://stackoverflow.com/questions/2429642/why-its-impossible-to-throw-exception-from-tostring
> >
> > Instead of throwing some nonsense "you're not allowed to throw from here"
> > error-message, how about actually unwinding the stack and passing the
> > exception to the global exception-handler?
> >
> > I understand there's a technical limitation making it
> difficult/impossible
> > to handle exceptions during __toString() - and it looks like you can
> still
> > try {...} catch (Exception $e) in __toString() just fine, but then what?
> > You have the exception, but you have no way to pass it to the standard
> > global exception-handler.
> >
> > If the script has to terminate either way, why not terminate the same way
> > an unhandled exception would normally cause the script to terminate?
> >
> > E.g. output the actual error-message, or pass it to whatever was
> registered
> > with register_exception_handler() so it can be output or handled in the
> > usual way?
> >
>
>
> The reason is that toString can be triggered from a lot of internal places.
> If an exception is thrown and caught within toString, it's not a problem.
> The problem is if the exception escapes toString, because it thus means
> that the code invoking toString must be interrupted.
>
> We in fact have no guarantee that all those internal places will work
> consistently/correctly in the presence of an exception, and if the engine
> will remain in a state that allows executing code afterward.
> Not executing code means we need to bypass error handlers as well.
>
> Handling an exception from internal code is a "manual" procedure, and code
> written that relies on conversions to strings may not have been written
> with support for exceptions in mind.
>
> I guess the alternative approach is to allow exceptions, review the code
> (i.e. a lot of work), and eventually fix reports as they come in.
>
> Best,
>
> --
> Etienne Kneuss
>
if somebody thinks that these kind of vulnerabilities are hypotetical, we
had a bunch of Interruption Vulnerabilities in the past and this could
potentionally introduce a lot more, but I think that this is something that
we have to resolve sooner or later, otherwise a whole bunch of proposed
features can never be introduced (for example accepting ArrayObjects
everywhere where array is accepted).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
