Re: [PHP-DEV] Fwd: Proper VARIANT to use for System.Security.Cryptography.RNGCryptoServiceProvider?

2015-10-20 Thread Pierre Joye
On Oct 20, 2015 5:44 PM, "Pierre Joye"  wrote:
>
> Hi,
>
> On Oct 19, 2015 9:52 PM, "Scott Arciszewski"  wrote:
> >
> > Okay, I've tried both wind...@lists.php.net and
> > php.wind...@lists.php.net and I give up trying there.
> >
> > --
> >
> > Since CAPICOM is deprecated, for users without ext/mcrypt or
> > ext/openssl, I'd like random_compat to work on Windows 7 and later.
> >
> > $rng = new DOTNET(
> > 'mscorlib',
> > 'System.Security.Cryptography.RNGCryptoServiceProvider'
> > );
> > $variant = new Variant($mystery_one, $mystery_two);
> > $bytes = $rng->GetBytes($variant);
> >
> > Can anyone tell me what to use for $mystery_one and $mystery_two? I
> > can't make heads or tails of ext/com_dotnet in php-src.
> >
> > References:
> >
> >
http://stackoverflow.com/questions/6497670/calling-rngcrypto-from-coms-dotnet-class-from-php
> > https://github.com/paragonie/random_compat/issues/67
> >
http://community.sitepoint.com/t/php-and-net-secure-rndnum-generation-using-dotnet-class/86511
> >
> > Scott Arciszewski
> > Chief Development Officer
> > Paragon Initiative Enterprises 
>
> Why not rely on openssl? Which uses the windows c-rng?

Correcting the word, to request users to enable openssl on windows sounds
like the only sane option to me. And it is always part of the distribution.

> I do not consider dotnet anywhere close to stable now, and almost never
available.

> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >


Re: [PHP-DEV] Fwd: Proper VARIANT to use for System.Security.Cryptography.RNGCryptoServiceProvider?

2015-10-20 Thread Pierre Joye
Hi,

On Oct 19, 2015 9:52 PM, "Scott Arciszewski"  wrote:
>
> Okay, I've tried both wind...@lists.php.net and
> php.wind...@lists.php.net and I give up trying there.
>
> --
>
> Since CAPICOM is deprecated, for users without ext/mcrypt or
> ext/openssl, I'd like random_compat to work on Windows 7 and later.
>
> $rng = new DOTNET(
> 'mscorlib',
> 'System.Security.Cryptography.RNGCryptoServiceProvider'
> );
> $variant = new Variant($mystery_one, $mystery_two);
> $bytes = $rng->GetBytes($variant);
>
> Can anyone tell me what to use for $mystery_one and $mystery_two? I
> can't make heads or tails of ext/com_dotnet in php-src.
>
> References:
>
>
http://stackoverflow.com/questions/6497670/calling-rngcrypto-from-coms-dotnet-class-from-php
> https://github.com/paragonie/random_compat/issues/67
>
http://community.sitepoint.com/t/php-and-net-secure-rndnum-generation-using-dotnet-class/86511
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises 

Why not rely on openssl? Which uses the windows c-rng?

I do not consider dotnet anywhere close to stable now, and almost never
available.

> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


[PHP-DEV] Re: [PHP-CVS] com php-src: FPM: change "listen = port" behavior from IPv4 catch-all to IPv6 catch-all (+ IPv4-mapped): UPGRADING sapi/fpm/fpm/fpm_sockets.c sapi/fpm/php-fpm.conf.in

2015-10-20 Thread Remi Collet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 20/10/2015 15:34, Antony Dovgal a écrit :
> Hello Remi.
> 
> I do understand that I'm a bit late with this one, but this patch 
> actually FORCES IPv6 for port-only syntax. I've got both IPv6 and
> IPv4 configured and getaddrinfo() returns only 1 address - the IPv6
> one. This happens because "::" seems to be a shorthand for "::1".

No, this is a shorthand for "all addresses"

> So when no hostname is specified FPM always tries to listen on IPv6
> only instead of doing what the patch was intended to do. The only
> way to force IPv4 is to specify IP address or a hostname 
> ("localhost" is enough).
> 
> This either needs to be fixed, or reflected in the docs.

I think this is in the comments

PHP 5.x
>> -;   'port'   - to listen on a TCP socket to all IPv4 -;
>> addresses on a specific port; -;   '[::]:port'  - to listen on a
>> TCP socket to all addresses ;  (IPv6 and
>> IPv4-mapped) on a specific port;

PHP 7.x
>> +;   'port'   - to listen on a TCP socket to all addresses ;
>> (IPv6 and IPv4-mapped) on a specific port;

Test with
   listen = 9070

# netstat -putan  | grep 9070
tcp6   0  0 :::9070  :::*  LISTEN  28371/php-fpm: mast

# fcgiget localhost4:9070/ping
..
pong


# fcgiget localhost6:9070/ping
..
pong

So it works on "modern" distro.

Perhaps a "IPv4-mapped when supported" in the comment.

Remi.


P.S. and this was applied only in 7.0,
especially to avoid breakage on "old" distro running 5.x

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlYmSxcACgkQYUppBSnxahgvzACfeWY9fArWcGbl7kV34SEKtdam
PzQAnRyTsY6nTlr8mop0xr98jZsvLhNL
=5OXR
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Issues with exceptions and overloading opcodes

2015-10-20 Thread Derick Rethans
Hi!

When hacking on Xdebug for PHP 7, I ran into some issues where PHP would 
just spin around. This happens when there is an exception, and I use 
overloaded opcodes. I wrote a small example extension at 
https://github.com/derickr/php-minimal-opcode-overloading-example with a 
test case 
(https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php)
 
that shows that something is looping in executing opcodes, as the 
HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this 
is a recent enough change, as it only started happening after I upgraded 
from about RC1 to latest master.

Would you care to have a look?

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] [RFC] [VOTE] Class Constant Visibility

2015-10-20 Thread Sean DuBois
Hey list,

Time for a simple RFC (in theory)!

I would like to add visibility modifiers to class constants, and then
as a nice added bonus give more info from the Reflection API (constants
now are a dedicated class so nice things like doc comments)

https://wiki.php.net/rfc/class_const_visibility

thanks!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Issues with exceptions and overloading opcodes

2015-10-20 Thread Bob Weinand

> Am 20.10.2015 um 18:08 schrieb Derick Rethans :
> 
> On Tue, 20 Oct 2015, Bob Weinand wrote:
> 
>>> Am 20.10.2015 um 17:11 schrieb Xinchen Hui :
>>> 
>>> On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans >> > wrote:
>>> 
 When hacking on Xdebug for PHP 7, I ran into some issues where PHP 
 would just spin around. This happens when there is an exception, 
 and I use overloaded opcodes. I wrote a small example extension at 
 https://github.com/derickr/php-minimal-opcode-overloading-example 
 with a test case ( 
 https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
  
 ) that shows that something is looping in executing opcodes, as the 
 HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe 
 this is a recent enough change, as it only started happening after 
 I upgraded from about RC1 to latest master.
 
 Would you care to have a look?
 
>>> This is introduced by a fix made by Bob, 
>>> https://github.com/php/php-src/commit/808f62bb 
>>> 
>>> 
>>> Bob, I am going to revert this for now, since you didn't include a 
>>> test script to show where the problem was, I am not sure why you 
>>> made this?
>> 
>> I didn't add any test case as we don't have any APIs in php-src using 
>> that user_opcode handler. I discussed the change back then with Dmitry 
>> and committed with his review.
>> 
>> It concretely broke uopz which might throw an exception itself. And in 
>> turn we realized that for integrity we need to ensure that opline == 
>> EX(opline) else we'll end up with different behavior in global 
>> register builds and normal builds.
>> 
>> In general, you should not overload ZEND_HANDLE_EXCEPTION (if you need 
>> to, have a special handling for it, but never directly dispatch to 
>> it). It is quite special being the only opcode actually allowing 
>> EG(exception) to be non-NULL at the start of it.
>> 
>> You are doing an #ifdef ZTS to exempt it… why don't you always exempt 
>> it?
> 
> Even if I do (like I've just pushed into the extension), the test still 
> fails because the code loops. So you did break something.
> 
> cheers,
> Derick
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Ah, ZEND_CATCH indeed also allows EG(exception) to be non-null…

… maybe I should write

if (EG(exception)
 && opline->opcode != ZEND_HANDLE_EXCEPTION && opline->opcode != ZEND_CATCH
 && ret != ZEND_USER_OPCODE_DISPATCH && ret != ZEND_USER_OPCODE_RETURN && ret 
!= ZEND_USER_OPCODE_ENTER && ret != ZEND_USER_OPCODE_LEAVE) {
HANDLE_EXCEPTION();
}

to allow dispatching for these two opcodes too?

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Karma to vote on (my own) RFC and access to phpng-upgrading

2015-10-20 Thread Sean DuBois
Hey list,

I just created an RFC, and don't have karma to vote on it
https://wiki.php.net/rfc/class_const_visibility

Also I would like to be able to edit
https://wiki.php.net/phpng-upgrading

One of the most frustrating changes for extensions was that 's' and 'p' were 
changed
from 'int' -> 'size_t' nothing you can do to catch this statically. Would love 
to update
the page with this info and the script in-tree to check for this.

thanks!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Benchmark Results for PHP Master 2015-10-20

2015-10-20 Thread lp_benchmark_robot
Results for project PHP master, build date 2015-10-20 13:49:39+03:00
commit: 1146f4e84844502d5dd763ac56d25644b72d7cd5
revision date:  2015-10-20 16:59:03+08:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 
2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0beta3, with hash
1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+00:00

--
benchmark   relative   change since   change since
std_dev*   last run   baseline
--
:-)   Wordpress 4.2.2 cgi -T1  0.23% -0.26%  2.21%
:-)   Drupal 7.36 cgi -T1  0.61% -0.24%  1.02%
:-)   MediaWiki 1.23.9 cgi -T5000  0.37%  0.07%  2.57%
:-) bench.php cgi -T1  0.05%  0.35%  3.01%
:-)   micro_bench.php cgi -T1  0.01%  0.23%  1.10%
:-)mandelbrot.php cgi -T1  0.20%  0.27%  5.05%
--
Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
* Relative Standard Deviation (Standard Deviation/Average)

Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] Issues with exceptions and overloading opcodes

2015-10-20 Thread Bob Weinand
> Am 20.10.2015 um 17:11 schrieb Xinchen Hui :
> 
> Hey:
> 
> 
> 
> On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans  > wrote:
> 
>> Hi!
>> 
>> When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
>> just spin around. This happens when there is an exception, and I use
>> overloaded opcodes. I wrote a small example extension at
>> https://github.com/derickr/php-minimal-opcode-overloading-example with a
>> test case
>> (
>> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
>> )
>> that shows that something is looping in executing opcodes, as the
>> HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
>> is a recent enough change, as it only started happening after I upgraded
>> from about RC1 to latest master.
>> 
>> Would you care to have a look?
>> 
> This is introduced by a fix made by Bob,
> https://github.com/php/php-src/commit/808f62bb 
> 
> 
> Bob, I am going to revert this for now, since you didn't include a test
> script to show where the problem was,  I am not sure why you made this?
> 
> 
> thanks
> 
>> 
>> 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
>> 
> 
> 
> 
> -- 
> Xinchen Hui
> @Laruence
> http://www.laruence.com/ 
I didn't add any test case as we don't have any APIs in php-src using that 
user_opcode handler.
I discussed the change back then with Dmitry and committed with his review.

It concretely broke uopz which might throw an exception itself. And in turn we 
realized that for integrity we need to ensure that opline == EX(opline) else 
we'll end up with different behavior in global register builds and normal 
builds.

In general, you should not overload ZEND_HANDLE_EXCEPTION (if you need to, have 
a special handling for it, but never directly dispatch to it). It is quite 
special being the only opcode actually allowing EG(exception) to be non-NULL at 
the start of it.

You are doing an #ifdef ZTS to exempt it… why don't you always exempt it?

Bob

Re: [PHP-DEV] Issues with exceptions and overloading opcodes

2015-10-20 Thread Derick Rethans
On Tue, 20 Oct 2015, Bob Weinand wrote:

> > Am 20.10.2015 um 17:11 schrieb Xinchen Hui :
> > 
> > On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans  > > wrote:
> > 
> >> When hacking on Xdebug for PHP 7, I ran into some issues where PHP 
> >> would just spin around. This happens when there is an exception, 
> >> and I use overloaded opcodes. I wrote a small example extension at 
> >> https://github.com/derickr/php-minimal-opcode-overloading-example 
> >> with a test case ( 
> >> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
> >>  
> >> ) that shows that something is looping in executing opcodes, as the 
> >> HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe 
> >> this is a recent enough change, as it only started happening after 
> >> I upgraded from about RC1 to latest master.
> >> 
> >> Would you care to have a look?
> >> 
> > This is introduced by a fix made by Bob, 
> > https://github.com/php/php-src/commit/808f62bb 
> > 
> > 
> > Bob, I am going to revert this for now, since you didn't include a 
> > test script to show where the problem was, I am not sure why you 
> > made this?
>
> I didn't add any test case as we don't have any APIs in php-src using 
> that user_opcode handler. I discussed the change back then with Dmitry 
> and committed with his review.
> 
> It concretely broke uopz which might throw an exception itself. And in 
> turn we realized that for integrity we need to ensure that opline == 
> EX(opline) else we'll end up with different behavior in global 
> register builds and normal builds.
> 
> In general, you should not overload ZEND_HANDLE_EXCEPTION (if you need 
> to, have a special handling for it, but never directly dispatch to 
> it). It is quite special being the only opcode actually allowing 
> EG(exception) to be non-NULL at the start of it.
> 
> You are doing an #ifdef ZTS to exempt it… why don't you always exempt 
> it?

Even if I do (like I've just pushed into the extension), the test still 
fails because the code loops. So you did break something.

cheers,
Derick
-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Issues with exceptions and overloading opcodes

2015-10-20 Thread Xinchen Hui
+bob

On Tue, Oct 20, 2015 at 11:11 PM, Xinchen Hui  wrote:

> Hey:
>
>
>
> On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans  wrote:
>
>> Hi!
>>
>> When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
>> just spin around. This happens when there is an exception, and I use
>> overloaded opcodes. I wrote a small example extension at
>> https://github.com/derickr/php-minimal-opcode-overloading-example with a
>> test case
>> (
>> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
>> )
>> that shows that something is looping in executing opcodes, as the
>> HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
>> is a recent enough change, as it only started happening after I upgraded
>> from about RC1 to latest master.
>>
>> Would you care to have a look?
>>
> This is introduced by a fix made by Bob,
> https://github.com/php/php-src/commit/808f62bb
>
> Bob, I am going to revert this for now, since you didn't include a test
> script to show where the problem was,  I am not sure why you made this?
>
>
> thanks
>
>>
>> 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
>>
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/


Re: [PHP-DEV] Password_hash salt generation refactor

2015-10-20 Thread Tom Worster
On 10/19/15, 6:43 PM, "Ángel González"  wrote:
>Tom Worster wrote:
>
>  I've verified that password_hash() without /dev/urandom can
>  produce systematically predictable salts, repeating a sequence of
>  just two salts. There's nothing statistical involved. Reported in
>  bug 70743.
>  
>  
>  Seems crypt() is similarly afflicted.
>
>
>Only providing two hashes *would* be very worrisome. Note however
>that you are crippling rand() by always resetting the seed (those

My point was to show that password_hash()'s promises of security are
nullified by use of an unrelated API. The docs do not explain how
password_hash() can depend on the use of other functions, like the
old rand() LCG, and there's no reason the user should suspect it.


>two different outputs appear because it is xoring with the same
>sequence). It's also reading unitialized memory in line 155, which
>is probably accounting for the salts being different every time. And
>a change in allocations for the first run being different.
>
>Whereas on a real world usage, even if a new php instance was used
>every time, you would need a GENERATE_SEED() collision. It
>initializes the seed using the timestamp, pid, microseconds and
>thread id (plus any state change caused if different php scripts
>were run).

Security BCPs do not allow arguments of this nature. Security-related
APIs need to be robust in all reasonable circumstances, not just in what
you consider typical circumstances.


>You have a very good point in that it would fail only if
>/dev/urandom does not exist at all, my initial concerns came from
>thinking that it could fail on a low-entropy case, but that won't
>happen on Linux (urandom always works), and even a urandom blocking
>OS (eg. on FreeBSD) wouldn't make it use the fallback code. Seems it
>would only be used if (a) you don't have a /dev/urandom at all or
>(b) it isn't the special file it is supposed to be (eg. it's a
>regular file). In which case you are running a broken OS :)
>So, changing my previous opinion, it'd be acceptable to drop it (I'd
>prefer it being done in the point release, though).

There's no such thing as "a low-entropy case" for our purposes. Once the
system's CSPRNG is seeded it will produce an endless supply of random
bytes. PHP has no alternative but to trust this. Anthony recently made
this point in a humorously obscene manner on Twitter.

/dev/random and /dev/urandom are the same thing on FreeBSD. The situation
on OpenBSD, NetBSD and OS X is similar.

FreeBSD's random device does not block except during a reseeding event.
This happens immediately after boot for a short period but PHP can safely
ignore that. The other causes for a reseeding event are very unlikely (and
have nothing to do with "how much entropy is consumed" or any such
nonsense) 
but if they do happen then the best thing PHP can do is hang and wait for
the result. I believe PHP can take the same attitude on OpenBSD, NetBSD
and 
OS X, although I admit I know less about these.

We do not need to consider low-entropy cases. If we read from urandom and
allow it to block, we should be safe. There is danger in libc arc4random
but that's for another thread #70744.

Tom



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



RE: [PHP-DEV] Password_hash salt generation refactor

2015-10-20 Thread Anatol Belski
Hi Anthony,

> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Monday, October 19, 2015 1:00 AM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Password_hash salt generation refactor
> 
> All,
> 
> With PHP 7 comes random_bytes and random_int. This duplicates some of
> the logic internally that password_hash uses to generate its salt.
> 
> I would like to refactor this to unify generation. I've opened a PR against
> master: https://github.com/php/php-src/pull/1585
> 
> I don't feel comfortable pulling against 7 this far into RC status.
> Perhaps wait until after it goes gold? Or should this target 7.1? It's not a 
> big
> deal in either direction. Though it does add a side-effect, where if it can't
> gather enough entropy it will throw an exception and return failure (where
> prior it would simply make a "best effort".
> 
> Thoughts?
> 
As much as it could be an improvement of the password_hash(), one would better 
avoid any behavior change at this stage. I was thinking about it and came to an 
idea that maybe could work for 7.0 - one should just make php_random_bytes() 
that side effect free.

Could php_random_bytes() be extended with a flag that would tell exceptions to 
pass? Or maybe exceptions could be moved out from the php_random_bytes() and 
thrown directly in the new functions that was undergoing the RFC but not 
password_hash() ? I'd be actually for the second variant. 

That ways FAILURE would be returned, but a decision about what to do about it 
would be made outside. IMHO it were also useful as the API is intended to be 
exported. So for the cases where php_random_bytes() came to use as a library 
function outside immediate PHP userspace (for example in SAPI), it should not 
throw exceptions from itself.

Do this suggestions sound eligible?

Regards

Anatol


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] php wiki registration

2015-10-20 Thread Félix Gagnon
Hey there. I just registered a wiki account with Zvax as username.

I intend mostly to continue hanging around on stack overflow's chat room as
this is where I've started being aware of all the internals discussions and
implications, see what's up with having a wiki account, and discover in
time if there is a way in which I can be useful.

thanks.

F.


[PHP-DEV] Re: Issues with exceptions and overloading opcodes

2015-10-20 Thread Xinchen Hui
Hey:



On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans  wrote:

> Hi!
>
> When hacking on Xdebug for PHP 7, I ran into some issues where PHP would
> just spin around. This happens when there is an exception, and I use
> overloaded opcodes. I wrote a small example extension at
> https://github.com/derickr/php-minimal-opcode-overloading-example with a
> test case
> (
> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
> )
> that shows that something is looping in executing opcodes, as the
> HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe this
> is a recent enough change, as it only started happening after I upgraded
> from about RC1 to latest master.
>
> Would you care to have a look?
>
This is introduced by a fix made by Bob,
https://github.com/php/php-src/commit/808f62bb

Bob, I am going to revert this for now, since you didn't include a test
script to show where the problem was,  I am not sure why you made this?


thanks

>
> 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
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/


[PHP-DEV] Re: Issues with exceptions and overloading opcodes

2015-10-20 Thread Derick Rethans
On Wed, 21 Oct 2015, Dmitry Stogov wrote:
>
> On Oct 20, 2015 6:11 PM, "Xinchen Hui"  wrote:
> 
> > On Tue, Oct 20, 2015 at 10:45 PM, Derick Rethans  wrote:
> >
> >> When hacking on Xdebug for PHP 7, I ran into some issues where PHP 
> >> would just spin around. This happens when there is an exception, 
> >> and I use overloaded opcodes. I wrote a small example extension at 
> >> https://github.com/derickr/php-minimal-opcode-overloading-example 
> >> with a test case ( 
> >> https://github.com/derickr/php-minimal-opcode-overloading-example/blob/master/tests/test.php
> >>  
> >> ) that shows that something is looping in executing opcodes, as the 
> >> HANDLE_EXCEPTION iirc doesn't advance to the next opline. I believe 
> >> this is a recent enough change, as it only started happening after 
> >> I upgraded from about RC1 to latest master.
> >>
> >> Would you care to have a look?
> >>
> > This is introduced by a fix made by Bob, 
> > https://github.com/php/php-src/commit/808f62bb
> >
> > Bob, I am going to revert this for now, since you didn't include a 
> > test script to show where the problem was, I am not sure why you 
> > made this?
>
> I think, we discussed that patch with Bob, and it looked right. May be 
> we missed some edge case...
> 
> It's not possible to write a test case for it.

I just did ;-) It requires loading this extension though!

In any case, it is causing a bug, and one that ought to be adressed 
before the next RC.

cheers,
Derick


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



[PHP-DEV] Re: [PHP-CVS] com php-src: FPM: change "listen = port" behavior from IPv4 catch-all to IPv6 catch-all (+ IPv4-mapped): UPGRADING sapi/fpm/fpm/fpm_sockets.c sapi/fpm/php-fpm.conf.in

2015-10-20 Thread Antony Dovgal

Hello Remi.

I do understand that I'm a bit late with this one, but this patch actually 
FORCES IPv6 for port-only syntax.
I've got both IPv6 and IPv4 configured and getaddrinfo() returns only 1 address 
- the IPv6 one.
This happens because "::" seems to be a shorthand for "::1".

So when no hostname is specified FPM always tries to listen on IPv6 only 
instead of doing what the patch was intended to do.
The only way to force IPv4 is to specify IP address or a hostname ("localhost" 
is enough).

This either needs to be fixed, or reflected in the docs.

Here's to demonstrate it:

288 if ((status = getaddrinfo(addr, port_str, , )) 
!= 0) {
(gdb)
294 for (p = servinfo; p != NULL; p = p->ai_next) {
(gdb) p *servinfo
$4 = {ai_flags = 0, ai_family = 10, ai_socktype = 1, ai_protocol = 6, ai_addrlen = 
28, ai_addr = 0xbdb3c0, ai_canonname = 0x0, ai_next = 0x0} < NO ai_next, so 
it's the only option.
(gdb) p addr
$5 = 0x8ace8c "::"



On 11/24/2014 08:38 AM, Remi Collet wrote:

Commit:95a609c5d14a2c5295886065a24db8344844ca8b
Author:Remi Collet  Mon, 24 Nov 2014 09:38:36 +0100
Parents:   d8fbcca725264cbca3ea88375bfb7879f81175d7
Branches:  master

Link:   
http://git.php.net/?p=php-src.git;a=commitdiff;h=95a609c5d14a2c5295886065a24db8344844ca8b

Log:
FPM: change "listen = port" behavior from IPv4 catch-all to IPv6 catch-all (+ 
IPv4-mapped)

Changed paths:
   M  UPGRADING
   M  sapi/fpm/fpm/fpm_sockets.c
   M  sapi/fpm/php-fpm.conf.in


Diff:
diff --git a/UPGRADING b/UPGRADING
index fe28213..9d5d8e7 100644
--- a/UPGRADING
+++ b/UPGRADING
@@ -63,6 +63,7 @@ PHP X.Y UPGRADE NOTES

  - FPM
. Fixed bug #65933 (Cannot specify config lines longer than 1024 bytes).
+  . Listen = port now listen on all addresses (IPv6 and IPv4-mapped).

  
  4. Deprecated Functionality
diff --git a/sapi/fpm/fpm/fpm_sockets.c b/sapi/fpm/fpm/fpm_sockets.c
index 0286f0e..e4e4948 100644
--- a/sapi/fpm/fpm/fpm_sockets.c
+++ b/sapi/fpm/fpm/fpm_sockets.c
@@ -268,6 +268,8 @@ static int fpm_socket_af_inet_listening_socket(struct 
fpm_worker_pool_s *wp) /*
} else if (strlen(dup_address) == strspn(dup_address, "0123456789")) { 
/* this is port */
port = atoi(dup_address);
port_str = dup_address;
+   /* IPv6 catch-all + IPv4-mapped */
+   addr = "::";
}

if (port == 0) {
@@ -275,18 +277,6 @@ static int fpm_socket_af_inet_listening_socket(struct 
fpm_worker_pool_s *wp) /*
return -1;
}

-   if (!addr) {
-   /* no address: default documented behavior, all IPv4 addresses 
*/
-   struct sockaddr_in sa_in;
-
-   memset(_in, 0, sizeof(sa_in));
-   sa_in.sin_family = AF_INET;
-   sa_in.sin_port = htons(port);
-   sa_in.sin_addr.s_addr = htonl(INADDR_ANY);
-   free(dup_address);
-   return fpm_sockets_get_listening_socket(wp, (struct sockaddr *) 
_in, sizeof(struct sockaddr_in));
-   }
-
/* strip brackets from address for getaddrinfo */
addr_len = strlen(addr);
if (addr[0] == '[' && addr[addr_len - 1] == ']') {
@@ -307,10 +297,10 @@ static int fpm_socket_af_inet_listening_socket(struct 
fpm_worker_pool_s *wp) /*
inet_ntop(p->ai_family, fpm_get_in_addr(p->ai_addr), tmpbuf, 
INET6_ADDRSTRLEN);
if (sock < 0) {
if ((sock = fpm_sockets_get_listening_socket(wp, 
p->ai_addr, p->ai_addrlen)) != -1) {
-   zlog(ZLOG_DEBUG, "Found address for %s, socket 
opened on %s", dup_address, tmpbuf);
+   zlog(ZLOG_DEBUG, "Found address for %s, socket 
opened on %s", addr, tmpbuf);
}
} else {
-   zlog(ZLOG_WARNING, "Found multiple addresses for %s, %s 
ignored", dup_address, tmpbuf);
+   zlog(ZLOG_WARNING, "Found multiple addresses for %s, %s 
ignored", addr, tmpbuf);
}
}

diff --git a/sapi/fpm/php-fpm.conf.in b/sapi/fpm/php-fpm.conf.in
index b2d8a22..850a369 100644
--- a/sapi/fpm/php-fpm.conf.in
+++ b/sapi/fpm/php-fpm.conf.in
@@ -155,9 +155,7 @@ group = @php_fpm_group@
  ;a specific port;
  ;   '[ip:6:addr:ess]:port' - to listen on a TCP socket to a specific IPv6 
address on
  ;a specific port;
-;   'port' - to listen on a TCP socket to all IPv4 addresses 
on a
-;specific port;
-;   '[::]:port'- to listen on a TCP socket to all addresses
+;   'port' - to listen on a TCP socket to all addresses
  ;(IPv6 and IPv4-mapped) on a specific port;
  ;   '/path/to/unix/socket' - to listen on a unix socket.
  ; Note: This value is mandatory.





--
Wbr,
Antony Dovgal
---
http://pinba.org -