Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87465
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
References: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
Date: Sat, 1 Aug 2015 00:34:32 +0200
Message-ID: <CAH-PCH6Cbr0DeY3Z=Ju0PfxKggeOCZaGbLLRrYD99GEXWO_j6Q@mail.gmail.com>
To: Sammy Kaye Powers <me@sammyk.me>, Nikita Popov <nikic@php.net>, Anthony Ferrara <ircmaxell@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0158c29c77e644051c336c63
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From: tyra3l@gmail.com (Ferenc Kovacs)

--089e0158c29c77e644051c336c63
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers <me@sammyk.me> wrote:

> Hello lovely PHP nerds,
>
> There are two open PR's for PHP7 to modify the behavior of the CSPRNG's:
>
> https://github.com/php/php-src/pull/1397 (main discussion)
> https://github.com/php/php-src/pull/1398
>
> Currently the random_*() functions will issue a warning and return false =
if
> a good source of random cannot be found. This is a potential security hol=
e
> in the event the RNG fails and returns false which gets evaluated as 0 in=
 a
> cryptographic context.
>
> To prevent this exploit the proposed behavior will throw an Exception whe=
n
> the RNG fails or certain argument validation fails. This also gives the
> developer a graceful way to fall back to an alternate CSPRNG.
>
> Since the core functions in PHP don't throw Exceptions, there is debate o=
n
> whether or not this change should be implemented. Some say the CSPRNG's
> should get a special pass since they will be relied on for cryptography. =
If
> we can't throw Exceptions, there were suggestions of raising a fatal erro=
r
> if the RNG fails.
>
> I think the argument can be boiled down to consistency vs security. We'd
> love to hear your feedback to decide what we should do in this context. :=
)
>
> Thanks,
> Sammy Kaye Powers
> sammyk.me
>
> Chicago, IL 60604
>

I would vote for E_WARNING and return false.
This can be wrapped in an oop wrapper in userland if somebody prefers and
exception but would still keep the procedural style as first class citizen.
Plus this would be consistent with other security/crypto related errors
like mcrypt_encrypt() getting an invalid key/iv
Nikita, Anthony what do you think?

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--089e0158c29c77e644051c336c63--