Edit report at https://bugs.php.net/bug.php?id=69833&edit=1
ID: 69833
Updated by: ab@php.net
Reported by: iand at ekit-inc dot com
Summary: mcrypt broken in 5.6.10 fd caching not working
Status: Closed
Type: Bug
Package: mcrypt related
Operating System: Solaris 9,10
PHP Version: 5.6.10
Assigned To: leigh
Block user comment: N
Private report: N
New Comment:
Bakported into 5.6 now, please check.
@leigh btw wasn't it actually an ABI breach adding a new member to the globals struct in PhP5?
Maybe with very low risk to be breaching something indeed, but just to mention ;)
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2015-08-11 14:55:12] ab@php.net
Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=80bc2133cd453c9a5981023d27e37bfd845172a1
Log: fix bug #69833 mcrypt fd caching not working
------------------------------------------------------------------------
[2015-08-10 07:37:01] ab@php.net
@iand, you can just check with the current master, it's already in there. If it's ok, it
can be backported into 5.6 branch.
Thanks.
------------------------------------------------------------------------
[2015-08-10 03:53:49] iand at ekit-inc dot com
I'll try the patch mentioned here
http://git.php.net/?p=php-src.git;a=commitdiff;h=a94ea9c97a5331d416c6256e5b01645188182054
against 5.6.12
------------------------------------------------------------------------
[2015-08-10 03:23:41] iand at ekit-inc dot com
My patch doesn't fix the reported problem; it was just on observation
that it could fix some other case where fd was 0.
I did some debugging a few weeks back but was unable to identify
what was going on; I strongly suspect there is some thread unsafe
code here and extra locking may be required for the threaded apache's.
For my own use I simply reversed the changes there were made in 5.6.10
so I'm running the 5.6.9 version of mcrypt.c happily in 5.6.11
------------------------------------------------------------------------
[2015-08-09 16:56:10] ab@php.net
@leigh, ok, i can tell why it is zero now, see http://git.php.net/?p=php-src.git;a=commitdiff;h=a94ea9c97a5331d416c6256e5b01645188182054
. I was already wondering as it's already at the first request. @iand, please give the patch a
try with php7.
Normally system could reuse stdin if ulimit was reached or it was explicitly closed. But merely it
seems globals was never properly initialized if ZTS mode. So zero is just an unitialized value, not
something open() has delivered. What is left for this ticket were
- backport to 5.6
- for 7 - integrate the static tsrmls cache
@leigh, let me know if you want to take that over (as it's still assigned to you). I think
CSPRNG part sohuldn't be applied, there the globals are handled correctly, so zero it could be
only in some exceptional case i've mentioned above. Instead there should be some conditions to
avoid a dead loop in both mcrypt and CSPRNG.
Thanks.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=69833
--
Edit this bug report at https://bugs.php.net/bug.php?id=69833&edit=1