On Tue, Jul 14, 2015 at 5:10 PM, Dean Eigenmann <dean.eigenm...@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 <m...@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
