Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87175
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.175 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
References: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
Date: Wed, 15 Jul 2015 17:27:28 +0900
Message-ID: <CAGa2bXY6LFsgvfDAPaWrcV6b=Yj2hsrqZRJ-6rRZDy=mXCnSHA@mail.gmail.com>
To: Sammy Kaye Powers <me@sammyk.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114713b80cdc0a051ae5bc1b
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a114713b80cdc0a051ae5bc1b
Content-Type: text/plain; charset=UTF-8

Hi Sammy,

On Wed, Jul 15, 2015 at 6:04 AM, Sammy Kaye Powers <me@sammyk.me> wrote:

> 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 hole
> 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 when
> 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 on
> 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 error
> 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. :)
>

I prefer exception rather than error.

However, I would not like to see exception in "some" functions.
It's whether we use exception for builtin functions or not.

I understand the risk, but users should handle all errors properly
to be secure anyway.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a114713b80cdc0a051ae5bc1b--