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

2015-10-19 Thread lp_benchmark_robot 
Results for project PHP master, build date 2015-10-19 10:08:24+03:00
commit: 620daef1e253dc841f5dcb24976e5378c296e8cd
revision date:  2015-10-18 17:20:17-07: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.15% -0.79%  2.48%
:-)   Drupal 7.36 cgi -T1  0.51%  0.44%  1.26%
:-)   MediaWiki 1.23.9 cgi -T5000  0.66%  0.65%  2.50%
:-) bench.php cgi -T1  0.14%  0.00%  2.67%
:-|   micro_bench.php cgi -T1  0.01% -0.23%  0.87%
:-)mandelbrot.php cgi -T1  0.31% -0.41%  4.80%
--
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] Re: Forbid rebinding scope of closures created by ReflectionFunctionAbstract::getClosure()

2015-10-19 Thread Anatol Belski 
Hi Alexander,

> -Original Message-
> From: Alexander Lisachenko [mailto:lisachenko...@gmail.com]
> Sent: Monday, October 19, 2015 10:19 AM
> To: Anatol Belski 
> Cc: Xinchen Hui ; Nikita Popov ;
> Dmitry Stogov ; PHP internals 
> Subject: Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by
> ReflectionFunctionAbstract::getClosure()
> 
> Hello, internals!
> 
> Just noticed this thread and want to clarify some things with getClosure()
> method. If i understood correctly, ReflectionFunctionAbstract::getClosure()
> should return non-rebindable closure ONLY for internal functions, but for
> userland functions binding should be still possible, right?
> 
> E.g.
> 
> class Foo {private $a=1;}
> 
> function test() {
> var_dump($this);
> }
> $closure = (new \ReflectionFunction('test'))->getClosure();
> $object = new Foo;
> $closure = $closure->bindTo($object, get_class($object)); $closure();
> 
> (unfortunately, it's broken: https://3v4l.org/YeDBj#v700rc5)
> 
> I know, that binding functions to objects is tricky, but this can be useful 
> for utility
> classes. But if you insist on this, ok, it's very rare case, just one single 
> example.
> 
> What is more important for me is ability to work with methods as closures.
> So my main concern is about restrictions of ReflectionMethod->getClosure() and
> rebinding.
> 
> See this example:
> 
> class Foo {private $a=1;}
> 
> class Bar {
> function test() {
> var_dump($this);
> }
> }
> $closure = (new \ReflectionMethod('Bar','test'))->getClosure(new Bar); $object
> = new Foo; $closure = $closure->bindTo($object, get_class($object)); 
> $closure();
> 
> This kind of rebinding is heavily used by Go! Aspect-Oriented Framework and
> now it will be broken (see https://3v4l.org/cZtbI#v700rc5). I think there 
> will be
> some more frameworks/libraries that use reflection and closure rebinding via
> reflections. So this introduced patch for RC5 is definitely a BC break for 
> existing
> code.
> Could you please provide a workaround or alternative ways to keep it working?
> Maybe, restrict rebinding only for internal objects/methods will be enough? Or
> only for ReflectionFunctionAbstract->getClosure(), but not for
> ReflectionMethod->getClosure()
> 
This way it was re-enabled in RC5.
getClosure();
$object = new Foo;
$closure = $closure->bindTo($object, get_class($object)); $closure();

I'm not sure the first case you brought has no impact. If it doesn't, it should 
be probably fixed as well. But the second one was the exact goal of the change.

Regards

Anatol


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

Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by ReflectionFunctionAbstract::getClosure()

2015-10-19 Thread Nikita Popov 
On Mon, Oct 19, 2015 at 10:18 AM, Alexander Lisachenko <
lisachenko...@gmail.com> wrote:

> Hello, internals!
>
> Just noticed this thread and want to clarify some things with getClosure()
> method. If i understood correctly, ReflectionFunctionAbstract::getClosure()
> should return non-rebindable closure ONLY for internal functions, but for
> userland functions binding should be still possible, right?
>
> E.g.
>
> class Foo {private $a=1;}
>
> function test() {
> var_dump($this);
> }
> $closure = (new \ReflectionFunction('test'))->getClosure();
> $object = new Foo;
> $closure = $closure->bindTo($object, get_class($object));
> $closure();
>
> (unfortunately, it's broken: https://3v4l.org/YeDBj#v700rc5)
>
> I know, that binding functions to objects is tricky, but this can be
> useful for utility classes. But if you insist on this, ok, it's very rare
> case, just one single example.
>
> What is more important for me is ability to work with methods as closures.
> So my main concern is about restrictions of ReflectionMethod->getClosure()
> and rebinding.
>
> See this example:
>
> class Foo {private $a=1;}
>
> class Bar {
> function test() {
> var_dump($this);
> }
> }
> $closure = (new \ReflectionMethod('Bar','test'))->getClosure(new Bar);
> $object = new Foo;
> $closure = $closure->bindTo($object, get_class($object));
> $closure();
>
> This kind of rebinding is heavily used by Go! Aspect-Oriented Framework
> and now it will be broken (see https://3v4l.org/cZtbI#v700rc5). I think
> there will be some more frameworks/libraries that use reflection and
> closure rebinding via reflections. So this introduced patch for RC5 is
> definitely a BC break for existing code.
> Could you please provide a workaround or alternative ways to keep it
> working? Maybe, restrict rebinding only for internal objects/methods will
> be enough? Or only for ReflectionFunctionAbstract->getClosure(), but not
> for ReflectionMethod->getClosure()
>

This change is primarily targeting userland methods, so your use-case is
exactly the one this is supposed to prevent. Note that you can still use
->bindTo($object). The only thing you cannot do is ->bindTo($object,
get_class($object)).

Nikita

Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by ReflectionFunctionAbstract::getClosure()

2015-10-19 Thread Alexander Lisachenko 
2015-10-19 12:19 GMT+03:00 Nikita Popov :

> This change is primarily targeting userland methods, so your use-case is
> exactly the one this is supposed to prevent. Note that you can still use
> ->bindTo($object). The only thing you cannot do is ->bindTo($object,
> get_class($object)).



It's very pity ( It was a very interesting feature that gives a birth for
userland AOP, without it part of framework functionality *will be lost*.
>From the list of attached bugs I can see that all weird stuff happens only
with internal classes/functions/methods. I never have seen a segfaults in
my code that heavily uses closure rebinding with userland methods/classes
and expect it to work in all future versions of PHP, starting from >=5.4.

I don't know PHP engine well, but this feature with scope rebinding for
methods allows some interesting patterns, like "Spy", "Field initializer",
"Lazy proxy initializer", etc. We just take one method and bind it to
another scope to perform an additional logic if needed.

Maybe, apply your patch only to internal functions (restrict them to have
$this inside) and simple functions? This will cover most bugs, but won't
break an exisitng code.

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-19 Thread Derick Rethans 
On Thu, 15 Oct 2015, Rowan Collins wrote:

> Korvin Szanto wrote on 14/10/2015 23:55:
> > If I capture the result of a "void" method and check if my result variable
> > with isset(), I'll get false. This sounds like it's void of value to me.
> 
> But why "invent" (as far as PHP is concerned) this new keyword of "void" to
> mean exactly the same thing "null" already means - absence of a definite
> value?

It's already "invented" for PHP anyway: 
http://docs.hhvm.com/manual/en/hack.annotations.examples.php - example 
2.

cheers,
Derick

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

Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by ReflectionFunctionAbstract::getClosure()

2015-10-19 Thread Alexander Lisachenko 
Hello, internals!

Just noticed this thread and want to clarify some things with getClosure()
method. If i understood correctly, ReflectionFunctionAbstract::getClosure()
should return non-rebindable closure ONLY for internal functions, but for
userland functions binding should be still possible, right?

E.g.

class Foo {private $a=1;}

function test() {
var_dump($this);
}
$closure = (new \ReflectionFunction('test'))->getClosure();
$object = new Foo;
$closure = $closure->bindTo($object, get_class($object));
$closure();

(unfortunately, it's broken: https://3v4l.org/YeDBj#v700rc5)

I know, that binding functions to objects is tricky, but this can be useful
for utility classes. But if you insist on this, ok, it's very rare case,
just one single example.

What is more important for me is ability to work with methods as closures.
So my main concern is about restrictions of ReflectionMethod->getClosure()
and rebinding.

See this example:

class Foo {private $a=1;}

class Bar {
function test() {
var_dump($this);
}
}
$closure = (new \ReflectionMethod('Bar','test'))->getClosure(new Bar);
$object = new Foo;
$closure = $closure->bindTo($object, get_class($object));
$closure();

This kind of rebinding is heavily used by Go! Aspect-Oriented Framework and
now it will be broken (see https://3v4l.org/cZtbI#v700rc5). I think there
will be some more frameworks/libraries that use reflection and closure
rebinding via reflections. So this introduced patch for RC5 is definitely a
BC break for existing code.
Could you please provide a workaround or alternative ways to keep it
working? Maybe, restrict rebinding only for internal objects/methods will
be enough? Or only for ReflectionFunctionAbstract->getClosure(), but not
for ReflectionMethod->getClosure()

Thanks!

2015-10-13 10:27 GMT+03:00 Anatol Belski :

> Hi,
>
> > -Original Message-
> > From: Xinchen Hui [mailto:larue...@php.net]
> > Sent: Tuesday, October 13, 2015 4:23 AM
> > To: Anatol Belski 
> > Cc: Nikita Popov ; Dmitry Stogov  >;
> > PHP internals 
> > Subject: Re: [PHP-DEV] Re: Forbid rebinding scope of closures created by
> > ReflectionFunctionAbstract::getClosure()
> >
> > Hey:
> >
> > On Tue, Oct 13, 2015 at 6:12 AM, Anatol Belski 
> > wrote:
> >
> > >
> > >
> > > > -Original Message-
> > > > From: Nikita Popov [mailto:nikita@gmail.com]
> > > > Sent: Monday, October 12, 2015 10:33 PM
> > > > To: Anatol Belski 
> > > > Cc: Dmitry Stogov ; PHP internals <
> > > internals@lists.php.net>
> > > > Subject: Re: [PHP-DEV] Re: Forbid rebinding scope of closures
> > > > created by
> > > > ReflectionFunctionAbstract::getClosure()
> > > >
> > > > On Mon, Oct 12, 2015 at 10:22 PM, Anatol Belski
> > > > 
> > > > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > > -Original Message-
> > > > > > From: Nikita Popov [mailto:nikita@gmail.com]
> > > > > > Sent: Monday, October 12, 2015 8:57 PM
> > > > > > To: Dmitry Stogov 
> > > > > > Cc: PHP internals ; Andrea Faulds
> > > > > > ;
> > > > > Stas
> > > > > > Malyshev ; Bob Weinand
> > ;
> > > > > > Anatol Belski 
> > > > > > Subject: [PHP-DEV] Re: Forbid rebinding scope of closures
> > > > > > created by
> > > > > > ReflectionFunctionAbstract::getClosure()
> > > > > >
> > > > > > > It would be great, if we stop any commits into PHP-7.0 except
> > > > > > > for
> > > > > > critical fixes now
> > > > > >
> > > > > > Maybe keep PHP-7.0 open (or as open as release branches usually
> > > > > > are),
> > > > > but from
> > > > > > now on only cherry-pick critical fixes into PHP-7.0.0 (instead
> > > > > > of merging everything)?
> > > > > >
> > > > > I commit myself to Dmitry's words. What matters today and
> > > > > especially after
> > > > > RC5 is the stability. Today we should invest into testing and bug
> > > > > fixes more than into improvements (aka fixes to something that is
> > > > > not broken). It really matters for the quality of the final.
> > > > > That's the message to convey probably.
> > > > >
> > > >
> > > > To rephrase my question: Should we treat PHP-7.0 the same way we
> > > > treat
> > > > PHP-5.6 and other release branches (i.e. all kinds of bug fixes are
> > > okay, even if
> > > > it's just improving a test or fixing some inconsequential behavior),
> > > > or
> > > do you
> > > > want to limit the PHP-7.0 branch to actually critical fixes now?
> > > > From
> > > what you
> > > > say, I assume the former rather than the latter?
> > > >
> > > Talking about "critical" I meant usual definitions as something that
> > > causes memory corruptions, data loss, big functional impact, security
> > > flaws, etc.
> > >
> > agree, bugs
> >
> > >
> > > The tricky point

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

2015-10-19 Thread Bob Weinand 

> Am 19.10.2015 um 11:46 schrieb Derick Rethans :
> 
> On Thu, 15 Oct 2015, Rowan Collins wrote:
> 
>> Korvin Szanto wrote on 14/10/2015 23:55:
>>> If I capture the result of a "void" method and check if my result variable
>>> with isset(), I'll get false. This sounds like it's void of value to me.
>> 
>> But why "invent" (as far as PHP is concerned) this new keyword of "void" to
>> mean exactly the same thing "null" already means - absence of a definite
>> value?
> 
> It's already "invented" for PHP anyway: 
> http://docs.hhvm.com/manual/en/hack.annotations.examples.php - example 
> 2.
> 
> cheers,
> Derick

When something is "invented" in Hack, … How is that related to PHP?
Hack is a language where a major equal subset is same as in PHP, yes. But 
that's still not a reason to say it were "invented" for PHP.

Please do not use Hack as ultima ratio here, it just is one language like C, 
Java etc. which happens to have more in common with PHP than most. But it still 
is just one other language. It's not PHP.

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

[PHP-DEV] Re: [RFC] Void Return Type (v0.2, reöpening)

2015-10-19 Thread Tom Worster 

Hi Andrea,

I'm very much in favor of this RFC.

It's not just useful, I think void return declarations are needed in 
order to establish sensible style rules for strict mode in real 
projects. To be strict in our programming practices, the absence of a 
return declaration signifies too many things in 7.0 -- it is excessively 
overloaded.


I summarized the discussions with my colleagues here:
http://thefsb.tumblr.com/post/131487359475

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-19 Thread Tom Worster 

On 10/18/15 7:39 PM, Ángel González wrote:

Korvin wrote:

+1 for 7.0.x security patch release, best effort sounds scary.

This is a salt. It doesn't need to be cryptographically secure. Using
php_rand()
there should pose no problem.
I would actually include that into the patch (move old lines 154-156
into the
FAILURE if).


A password salt needs to be unique. It does not need to be drawn from a 
CSPRNG but that is one of the few ways we can be reasonably confident of 
uniqueness (since, as usual, we assume the platform RNG is properly seeded).


I can seed php_rand() from my script but, other than using the platform 
RNG, I have no idea how. Or I can let PHP seed it but its algorithm, a 
function of time and PID, shows PHP doesn't know how either.


As PHP's version numbers increase, so should it's rigor in using best 
practices. I've no problem with apps breaking in the 5 -> 7 upgrade if 
they have no access to platform RNG. So doing Anthony's proposed change 
as early as possible in 7.0.x is best.


Tom


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

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

2015-10-19 Thread Scott Arciszewski 
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 

-- 
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-19 Thread Tom Worster 

On 10/19/15 3:43 PM, Scott Arciszewski wrote:

On Mon, Oct 19, 2015 at 1:00 PM, Chris Riley  wrote:

On 19 October 2015 at 16:22, Tom Worster  wrote:


On 10/18/15 7:39 PM, Ángel González wrote:


Korvin wrote:


+1 for 7.0.x security patch release, best effort sounds scary.


This is a salt. It doesn't need to be cryptographically secure. Using
php_rand()
there should pose no problem.
I would actually include that into the patch (move old lines 154-156
into the
FAILURE if).



A password salt needs to be unique. It does not need to be drawn from a
CSPRNG but that is one of the few ways we can be reasonably confident of
uniqueness (since, as usual, we assume the platform RNG is properly seeded).




A password salt should not be predictable, allowing a salt to potentially
become predictable is a bad idea. Solution is to use a CSPRNG for
generation of salts.


Hi all,

I'd like to weigh in by quantifying the predictability of rand(). If
you're well aware of statistics or versed in cryptography, you might
be able to skip this email. (You might still want to read it to help
verify or challenge my conclusion.)

First, for the sake of generosity, let's assume that rand() is
properly seeded, e.g. by 4 bytes from /dev/urandom, on each invocation
so that the pid + time() issue doesn't come into play. (In reality,
this is very important.)

After seeding rand, there are 2^32 possible outputs. That's a little
over 4 billion, and it's highly unlikely that your website has 4
billion user accounts with a hashed password, so that's good enough
right? Well, not quite.

For a moment, imagine you are in a room with 22 other people born in
the same year as you. What is the probability that any two people in
the room share the exact same birthday? Well, it turns out that the
answer is 50%. We call this the Birthday Problem.

 From studying this problem, we can estimate the number of random
samples to generate a collision from an n-bit keyspace by a simple
formula: G = 2^(n/2). This is called the Birthday Bound.

If you have a keyspace of 2^32 possible output sequences like we do
from rand(), we can say that after 65,536 there is a 50% probability
of finding at least one collision.

It should go without saying, but if users have weak/common password
choices and their salts collide, they will end up with duplicate
bcrypt hashes.

My conclusion is thus: Yes, we do need a CSPRNG here, especially if we
want to encourage the use of the password_* API for any large system.


I don't follow the logic of this hypothetical. php_rand() is *only* 
relevant to this discussion if PHP can't read /dev/random or 
CryptGenRandom, in which case we know that the state of php_rand()'s LCG 
is not randomized (it's open to tampering) so this statistical analysis 
is not possible.


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.

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-19 Thread Scott Arciszewski 
On Mon, Oct 19, 2015 at 1:00 PM, Chris Riley  wrote:
> On 19 October 2015 at 16:22, Tom Worster  wrote:
>
>> On 10/18/15 7:39 PM, Ángel González wrote:
>>
>>> Korvin wrote:
>>>
 +1 for 7.0.x security patch release, best effort sounds scary.

>>> This is a salt. It doesn't need to be cryptographically secure. Using
>>> php_rand()
>>> there should pose no problem.
>>> I would actually include that into the patch (move old lines 154-156
>>> into the
>>> FAILURE if).
>>>
>>
>> A password salt needs to be unique. It does not need to be drawn from a
>> CSPRNG but that is one of the few ways we can be reasonably confident of
>> uniqueness (since, as usual, we assume the platform RNG is properly seeded).
>>
>
>
> A password salt should not be predictable, allowing a salt to potentially
> become predictable is a bad idea. Solution is to use a CSPRNG for
> generation of salts.

Hi all,

I'd like to weigh in by quantifying the predictability of rand(). If
you're well aware of statistics or versed in cryptography, you might
be able to skip this email. (You might still want to read it to help
verify or challenge my conclusion.)

First, for the sake of generosity, let's assume that rand() is
properly seeded, e.g. by 4 bytes from /dev/urandom, on each invocation
so that the pid + time() issue doesn't come into play. (In reality,
this is very important.)

After seeding rand, there are 2^32 possible outputs. That's a little
over 4 billion, and it's highly unlikely that your website has 4
billion user accounts with a hashed password, so that's good enough
right? Well, not quite.

For a moment, imagine you are in a room with 22 other people born in
the same year as you. What is the probability that any two people in
the room share the exact same birthday? Well, it turns out that the
answer is 50%. We call this the Birthday Problem.

>From studying this problem, we can estimate the number of random
samples to generate a collision from an n-bit keyspace by a simple
formula: G = 2^(n/2). This is called the Birthday Bound.

If you have a keyspace of 2^32 possible output sequences like we do
from rand(), we can say that after 65,536 there is a 50% probability
of finding at least one collision.

It should go without saying, but if users have weak/common password
choices and their salts collide, they will end up with duplicate
bcrypt hashes.

My conclusion is thus: Yes, we do need a CSPRNG here, especially if we
want to encourage the use of the password_* API for any large system.

https://en.wikipedia.org/wiki/Birthday_problem
https://en.wikipedia.org/wiki/Birthday_attack
http://eprint.iacr.org/2005/004

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

--
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-19 Thread Chris Riley 
On 19 October 2015 at 16:22, Tom Worster  wrote:

> On 10/18/15 7:39 PM, Ángel González wrote:
>
>> Korvin wrote:
>>
>>> +1 for 7.0.x security patch release, best effort sounds scary.
>>>
>> This is a salt. It doesn't need to be cryptographically secure. Using
>> php_rand()
>> there should pose no problem.
>> I would actually include that into the patch (move old lines 154-156
>> into the
>> FAILURE if).
>>
>
> A password salt needs to be unique. It does not need to be drawn from a
> CSPRNG but that is one of the few ways we can be reasonably confident of
> uniqueness (since, as usual, we assume the platform RNG is properly seeded).
>


A password salt should not be predictable, allowing a salt to potentially
become predictable is a bad idea. Solution is to use a CSPRNG for
generation of salts.

[PHP-DEV] docs karma

2015-10-19 Thread Dmitry Zenovich 
Hi!

I want to refresh Runkit's documentation. Please give me access rights to
do this. My php.net account is dzenovich.

Thanks!