All, I'd like to move the conversation towards a decision regarding PRs 1397 and 1398. These decisions are blocking random_compat as well as a security enhancement to random_bytes (merge conflicts are *the worst*).
Here's a quick recap Arguments: 1. Consistency is more important than security. > random_* should be consistent with the rest of PHP (sans intdiv()). > They should return false and emit an E_WARNING > or E_ERROR warning (the latter is if we want it to fail closed). > > It's the responsibility of the developer to know this can > happen and explicitly check for it. Don't throw anything. 2. Security is more important than consistency. > Placing more responsibility on the developer increases the > likelihood of an implementation error. We should aim for compatible > usability with rand() and mt_rand() for random_int(), which never return > false. For random_int() and random_bytes(), should PHP be unable > to generate a random value (no random device available, file > descriptor exhaustion, etc.) an exception should be thrown. If the > developer wants to handle it gracefully, they can place it in try/catch > blocks (which raising errors make messy). Otherwise, the default > state is to fail closed (i.e. terminate script execution). Open Questions: 1. Under what conditions should an Exception be thrown, and which should throw an Error instead? Did I miss any? I'm in favor of throwing *something*. As for the particulars of what should be an Exception and what should be an Error, I don't have a horse in this race. Exceptions already existed and Errors were already accepted in the Throwable RFC, so I don't believe this warrants another RFC and putting this decision off until 7.1. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
