Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88866
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.43 as permitted sender)
To: Anthony Ferrara <ircmaxell@gmail.com>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAAyV7nGLiGC_E1YYc21chGSKdUJm1KpZV9V3_rZn5eHOmyEarA@mail.gmail.com>
Message-ID: <56242FE6.10000@gmail.com>
Date: Sun, 18 Oct 2015 16:48:54 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGLiGC_E1YYc21chGSKdUJm1KpZV9V3_rZn5eHOmyEarA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Password_hash salt generation refactor
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> 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

If functionality does not change and it's just internal refactoring not
breaking BC (both language and binary) then it can go into 7.0.x. From
what I can see, it is pretty unintrusive, so I wouldn't mind too much
even getting it into 7.0 but that's on RM to decide. In fact, at least
making php_random_bytes() public API should be in 7.0 as that makes for
much less compatibility problems for extensions later.
Generally speaking, having public random generating function sounds like
a very prudent thing, even if we end up not merging the rest of the
patch into 7.0.

> 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".

From what I can see, the system that can't return enough random bytes
for what php_random_bytes() wants is deeply fubar, so on this scenario
failing fast is the best option.

-- 
Stas Malyshev
smalyshev@gmail.com