Re: [PHP-DEV] Bug #70805 (Segmentation faults whilst running Drupal 8 test suite)
Hey Bob, Thanks, it was 2am and quite sleepy so wasn't considering the gen'd files. Thanks for clarifying! On Wed, Nov 4, 2015 at 2:26 AM, Bob Weinand wrote: > Hey, > > zend_vm_execute.h is an auto-generated file, via zend_vm_gen.php. In > reality the patch only fixes the code in exactly one location > (zend_vm_def.h) and then regenerated zend_vm_execute.h. > > Bob > > > Am 04.11.2015 um 03:10 schrieb Paul Dragoonis : > > > > Hey, > > > > Looking at the patch, the changes to zend_vm_def.h and zend_vm_execute.h > > are duplicated in 10 locations. I'm wondering if we can consolidate this > > into maintainable function/macro to handle this? > > > > On Wed, Nov 4, 2015 at 1:58 AM, Xinchen Hui wrote: > > > >> Hey: > >> > >> > >> > >> On Wed, Nov 4, 2015 at 3:58 AM, Dmitry Stogov wrote: > >> > >>> Hi, > >>> > >>> I think, I found the root problem of > >> https://bugs.php.net/bug.php?id=70805 > >>> > >>> unset($a) or unser($GLOBAL["a"]) triggered GC and destructors calls > that > >>> tried to release the same global variable $a once again. As result > it's > >>> reference counter was decremented twice and this caused use-after-free, > >>> double-free, etc. > >>> > >>> The proposed cumulative fix for all related problems: > >>> > >>> https://gist.github.com/dstogov/7aa9d24876e2b3fce8c5 > >>> > >>> Xinchen, could you please review and verify this once again, > >>> then add necessary tests and commit. > >>> > >> No problem, all issues we met are resovled , thanks :) > >> > >> tested and committed. > >> > >> and aslo thanks the fabian who provides us ssh access to a reproducible > box > >> (it's really hard to reproduce locally) > >> > >> thanks! > >> > >>> > >>> Thanks. Dmitry. > >>> > >> > >> > >> > >> -- > >> Xinchen Hui > >> @Laruence > >> http://www.laruence.com/ > >> > >
[PHP-DEV] Benchmark Results for PHP Master 2015-11-04
Results for project PHP master, build date 2015-11-04 05:26:46+02:00 commit: a4a767e6da477ae84e1c7e442fef64f99a4dbbc4 revision date: 2015-11-03 17:56:05-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 current rev run std_dev* last run baseline with PGO --- :-) Wordpress 4.2.2 cgi -T1 0.31% -0.39% 2.29% 7.57% :-) Drupal 7.36 cgi -T1 1.04% 0.95% 1.45% 3.80% :-) MediaWiki 1.23.9 cgi -T5000 0.27% -0.75% 1.57% 3.02% :-) bench.php cgi -T1 0.09% -0.35% 1.93% 7.19% :-) micro_bench.php cgi -T1 0.01% 1.03% 1.95% 4.40% :-)mandelbrot.php cgi -T1 0.11% -2.21% 2.80% 4.56% --- Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in fetches/second while all others are measured in seconds. More details on measurements methodology at: https://01.org/lp/documentation/php-environment-setup. * 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] Re: [PHP-CVS] com php-src: Remove arc4random: ext/standard/config.m4 ext/standard/random.c
On 11/2/15, 9:07 AM, "Anthony Ferrara" wrote: >Tom, > >> 3. arc4random puts a generator in the user process. >> >> This is much more controversial. Some people (Anthony F. for one and >>myself >> until recently) argue that a generator algorithm in the user process >> degrades security. It must in any case be downstream of the kernel >>source >> and therefore cannot compensate for any problems in using kernel >>randomness. >> Moreover, it adds another point of failure (a place where there might be >> bugs, like OpenSSL's RNG bugs). And finally, since the downstream >>generator >> is in the user process rather than protected kernel memory, it's easier >>for >> an attacker to learn the generator's state and thus predict future >>outputs. >> >> Others, including Dan Bernstein[1] and the OpenBSD crowd[2], argue that >>the >> later is theoretical rather than a practical vulnerability because if an >> attacker can read your memory then your crypto system is a total fail >> regardless where you get random numbers from. > >There is one important nuance here though. If an attacker can read >memory they they can compromise anything currently in memory for the >application. Things that have since been freed (such as tokens and >secrets generated from prior requests) are typically safe. However, >using a userland RNG, that's not necessarily true unless a reseed >(stir) event happened between them. So you do lose some practical >forward security in that things that otherwise may not have been >leaked may be leaked. So I would still consider it a practical >vulnerability. > >And an attacker reading memory is only game over if they can control >how and when that memory is read. It's a fail in any case, but if the >exploit only allows them to ever see memory from their request, it's a >lot less damaging than if they can see other's requests on the system. >It's still quite bad, but there's definitely a difference. A counter argument to this, iiuc, goes as follows. Imagine the PHP server process's RNG as a 32 byte key expanded into a very long string. Each call to get something random consumes a substring of some length. The next call consumes the next N bytes, and so forth. The order of these calls and how many bytes each consumes is unpredictable, so the argument goes. Even a relatively small diversity of uses for random bytes (diverse requests each with diverse calls) in the history of the process up to any given RNG call effectively stirs the RNG. This unpredictability can be considered a source of entropy under the same kind of definitions and assumptions that the kernel needs to gather entropy. As for my opinion, the argument is categorically invalid only in very special cases, pretty much irrelevant in PHP practice. In general cases, it's validity boils down to how much entropy one can believe is introduced this way and how often. This belief is clearly subjective. For me, as a PHP user, I get a lot of confidence from this argument. I only saw it properly set out very recently but I was using essentially the same thing against people who (having read the notorious Linux random(4) man page or having picked up the meme) said urandom is unsafe for crypto because you must not consume more entropy than you can gather. Granted, there's nothing estimating how much entropy is introduced this way. Granted, there's even more of this mixing if we all use the system's one central RNG. But I feel subjectively that it need introduce little unpredictability to make practical exploits of predicted future randoms very difficult. >Thanks again for the discussion It's my pleasure, an interesting topic, as yet unresolved among its cognoscenti. > >Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing ldap_connect documentation
On Tue, Nov 3, 2015 at 11:00 PM, Côme Chilliet wrote:
> What should be clear in the documentation :
> - The LDAP URI scheme is the recommended way to call ldap_connect
> - The ldap:// or ldaps:// is required
> - People can use host, port if they do not need SSL
>
Agreed.
> - Second parameter is not used if the first one is an LDAP scheme, so
> calling ldap_connect('ldap://localhost', 456) will use default port 389.
>
I'd prefer this raise a notice, like "Second argument ignored when using
URI syntax. Port will default to 389. Did you mean 'ldap://localhost:456'
instead?"
bishop
Re: [PHP-DEV] One last ldap_connect headache
On Tue, Nov 3, 2015 at 11:13 PM, Côme Chilliet wrote:
> I got mail from someone saying that in previous version, calling
> ldap_connect($host, NULL) would use default port.
> While now it is considered as trying to use port 0 and trigger an error.
>
I believe the current behavior (interpret as zero and trigger error) is
correct.
> I’m a bit troubled about it because the documentation says:
> resource ldap_connect ([ string $hostname = NULL [, int $port = 389 ]] )
> So $port defaults to 389 and not to NULL, and it says nothing about
> accepting NULL as second parameter.
>
Let's compare to another PHP function that takes a numeric optional
parameter with a non-zero default:
array array_unique ( array $array [, int $sort_flags = SORT_STRING ] )
Note that SORT_STRING === 2, SORT_REGULAR === 0.
If you pass null for the second argument, you get the SORT_REGULAR
behavior, not the default SORT_STRING behavior:
print_r(array_unique([ 1, '1', '1a' ], null));
That said, it does seem handful to be able to pass NULL to ask for default
> port without remembering which one it is.
> The context is something like:
> $port = NULL;
> if (isset($options['port'])) {
> $port = $options['port'];
> }
> $resource = ldap_connect($host, $port);
>
A few reasons I'd offer as arguments against this. $port is deprecated, so
why add features to deprecated arguments? Other PHP internal functions
don't behave this way (array_unique, socket_create_listen, ssh2_connect,
etc.), so why go against the grain? Why not document (in a comment) the
preferred way of doing this, which might be:
if (isset($options['port']))
$resource = ldap_connect($host, $options['port']);
else
$resource = ldap_connect($host);
> Right now it either needs an if statement or hardcoding 389 instead of
> NULL as the default. In the C code we use the constant LDAP_PORT for this
> but there is no such thing in PHP.
> Any ideas/comments about this?
>
A PHP user-land constant like LDAP_DEFAULT_PORT might help users out
marginally, but to my knowledge no other port numbers are exposed as such
in PHP. Like ssh2_connect, for example, uses a raw 22.
If one wanted truly robust (paranoid) code, you'd probably want to do:
$port = getservbyname('ldap', 'tcp');
if (isset($options['port']) && is_numeric($options['port']))
$port = intval($options['port']);
$resource = ldap_connect($host, $port);
And this could go in a comment and solve the whole issue without code
changes.
Re: [PHP-DEV] Fixing ldap_connect documentation
Le mercredi 4 novembre 2015, 21:10:09 Bishop Bettini a écrit :
> > - Second parameter is not used if the first one is an LDAP scheme, so
> > calling ldap_connect('ldap://localhost', 456) will use default port 389.
> >
>
> I'd prefer this raise a notice, like "Second argument ignored when using
> URI syntax. Port will default to 389. Did you mean 'ldap://localhost:456'
> instead?"
Good idea, this will avoid confusion. I will add this.
MCMic
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One last ldap_connect headache
Le mercredi 4 novembre 2015, 21:41:20 Bishop Bettini a écrit :
>
> If one wanted truly robust (paranoid) code, you'd probably want to do:
>
> $port = getservbyname('ldap', 'tcp');
>
> if (isset($options['port']) && is_numeric($options['port']))
> $port = intval($options['port']);
>
> $resource = ldap_connect($host, $port);
>
> And this could go in a comment and solve the whole issue without code
> changes.
Ok, so we could just put in the documentation the tip about getservbyname if
one does not want to use 389 directly.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fixing ldap_connect documentation
Does this seems correct? https://github.com/php/php-src/pull/1618 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
