Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107309
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 24 Sep 2019 10:11:11 +0200
References: <A91E718E-B023-42DC-AC8D-BC989F5A80E4@cschneid.com>
 <CAF+90c_75x0ZoD63CoLXY3kUKNQQuR_HhaO998osHuzV7ZGXuw@mail.gmail.com>
 <696dc114-c2df-40aa-aad6-5b87d4373c0e@www.fastmail.com>
 <CAEZPtU7fCC=zkr1DxzL9ZaAZXbmNe0RBWvy1XM5tpEmwvPYCRg@mail.gmail.com>
To: php internals <internals@lists.php.net>
In-Reply-To: <CAEZPtU7fCC=zkr1DxzL9ZaAZXbmNe0RBWvy1XM5tpEmwvPYCRg@mail.gmail.com>
Message-ID: <83A8831C-1570-4E62-BF37-06774C5FB26D@cschneid.com>
Subject: Re: RFCs should mention all BC breaks (was Re: [PHP-DEV] PHP 7.4 BC
 break with openssl_random_pseudo_bytes())
From: cschneid@cschneid.com (Christian Schneider)

Am 24.09.2019 um 06:18 schrieb Pierre Joye <pierre.php@gmail.com>:
> On Mon, Sep 23, 2019 at 10:17 PM Larry Garfield =
<larry@garfieldtech.com> wrote:
>=20
>> I cannot speak for OpenSSL,  but random_bytes() and random_int() were =
changed very late in the 7.0 cycle to throw exceptions so that they =
"fail closed".  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 time then you now have a security hole because you're =
using a constant seed for random-dependent behavior.
>>=20
>> That was a good change, and it should be kept that way, IMO.
>=20
> 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.


The main point of my original mail was stripped so I changed the subject =
to emphasise what I really care about.

So here is my question: Am I the only one who thinks BC breaks should be =
fully covered in an RFC before voting?

Regards,
- Chris