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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
<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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php