Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87174
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain paragonie.com from 209.85.220.177 cause and error)
MIME-Version: 1.0
In-Reply-To: <1179E626-A5F9-483E-9088-096C4FC46214@icloud.com>
References: <CALYT1Yo-ae+cemXaaXs5Jv5t2DSzdxdYuxuhEGbXyoo_863+bw@mail.gmail.com>
	<1179E626-A5F9-483E-9088-096C4FC46214@icloud.com>
Date: Tue, 14 Jul 2015 17:18:38 -0400
Message-ID: <CAKws9z182O5nYvrjFHBKq-mkOB4326BPVMEhC2ViLRacGqTHyQ@mail.gmail.com>
To: Dean Eigenmann <dean.eigenmann@icloud.com>
Cc: Sammy Kaye Powers <me@sammyk.me>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7
From: scott@paragonie.com (Scott Arciszewski)

On Tue, Jul 14, 2015 at 5:10 PM, Dean Eigenmann
<dean.eigenmann@icloud.com> wrote:
> Would a PHP Error not work in this case? Or would the error then be interpreted as the result?
>
>
>> On 14 Jul 2015, at 23:04, 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 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. :)
>>
>> Thanks,
>> Sammy Kaye Powers
>> sammyk.me
>>
>> Chicago, IL 60604
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

How can a developer gracefully and simply handle a fatal error?
Recommending that developers mess with set_error_handler() for one
very specific function seems like a bad design choice in my opinion.
An uncaught exception should kill the script, a caught exception can
let the developer decide how to proceed.

I'd vote in favor of Exceptions (which, by default, will fail closed
but can be handled gracefully through try-catch blocks) rather than
E_WARNING (which fails open) or E_ERROR (which doesn't allow for
graceful handling).

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises