On Thu, 6 Aug 2015 00:55 Scott Arciszewski <sc...@paragonie.com> wrote:
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 We also -need- a consensus in place because we have more security sensitive features targeting 7.1 and we don't want to have this argument again. Throwing exception's may not be consistent right now, but it certainly should be in the future. The transition to a new consistency has to start somewhere.
