Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87274
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.220.171 cause and error)
MIME-Version: 1.0
In-Reply-To: <836BA21C-AE99-4E7B-AB06-EBC30E41BA0E@icicle.io>
References: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
	<836BA21C-AE99-4E7B-AB06-EBC30E41BA0E@icicle.io>
Date: Fri, 24 Jul 2015 12:36:02 -0400
Message-ID: <CAKws9z2PQWT7rSsM5R9TD-O69Ovy7-eifAuF-S0BQhBh3z4h1w@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From: scott@paragonie.com (Scott Arciszewski)

On Thu, Jul 23, 2015 at 1:26 PM, Aaron Piotrowski <aaron@icicle.io> wrote:
>
>> On Jul 14, 2015, at 4: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 ho=
le
>> in the event the RNG fails and returns false which gets evaluated as 0 i=
n a
>> cryptographic context.
>>
>> To prevent this exploit the proposed behavior will throw an Exception wh=
en
>> 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 err=
or
>> 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
>
> How about instead of throwing an instance of Exception, the random_*() fu=
nctions throw an instance of Error on failure. A subclass of Error, such as=
 SecurityError could also be added. As it is unlikely that the failure of t=
hese functions to generate a random value could be handled at runtime, thro=
wing an instance of Error makes the most sense imho.
>
> Many internal functions can result in an instance of Error being thrown, =
particularly with declare(strict_types=3D1). So those looking for consisten=
cy can be satisfied that other internal functions already can behave simila=
rly, and those looking to fail closed can be satisfied that an exception wi=
ll be thrown if securely generating a random value fails.
>
> Aaron Piotrowski

I must have overlooked a detail here.

According to https://github.com/tpunt/PHP7-Reference#throwable-interface
there are Throwables called Error, as a separate designation from an
exception. I didn't see this in the engine exceptions RFC, so I was
unaware that was even a thing.

In this case, yes, as long as you can wrap it in try/catch blocks,
SecurityError which extends Error and/or implements Throwable is an
excellent suggestion.

Previously, I thought the suggestion was to stick to triggering errors
(E_ERROR, E_RECOVERABLE_ERROR, etc.).

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com>