Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107306
MIME-Version: 1.0
References: <A91E718E-B023-42DC-AC8D-BC989F5A80E4@cschneid.com>
 <CAF+90c_75x0ZoD63CoLXY3kUKNQQuR_HhaO998osHuzV7ZGXuw@mail.gmail.com> <696dc114-c2df-40aa-aad6-5b87d4373c0e@www.fastmail.com>
In-Reply-To: <696dc114-c2df-40aa-aad6-5b87d4373c0e@www.fastmail.com>
Date: Tue, 24 Sep 2019 11:18:35 +0700
Message-ID: <CAEZPtU7fCC=zkr1DxzL9ZaAZXbmNe0RBWvy1XM5tpEmwvPYCRg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 7.4 BC break with openssl_random_pseudo_bytes()
From: pierre.php@gmail.com (Pierre Joye)

On Mon, Sep 23, 2019 at 10:17 PM Larry Garfield <larry@garfieldtech.com> wr=
ote:

> I cannot speak for OpenSSL,  but random_bytes() and random_int() were cha=
nged very late in the 7.0 cycle to throw exceptions so that they "fail clos=
ed".  Otherwise if you expect a random value back but get a constant value =
(false or empty string), if you don't remember to check it yourself every t=
ime then you now have a security hole because you're using a constant seed =
for random-dependent behavior.
>
> That was a good change, and it should be kept that way, IMO.

Fully agree. This is actually pretty the only way to handle errors
with these functions. Anything else creates a risk that we could have
easily prevented.


Best,
--=20
Pierre

@pierrejoye | http://www.libgd.org