On Mon, Jul 27, 2015 at 1:04 PM, Rowan Collins <rowan.coll...@gmail.com> wrote: > Scott Arciszewski wrote on 27/07/2015 15:45: >> >> The problem with fatal errors is that "This function can fail >> irrecoverably outside of your control" isn't going to encourage >> adoption. > > > Well... rats! ;) > > It seems whatever we do here is going to carry some kind of risk / downside. > :(
Aye, unfortunately, we need to decide what our priorities are. I've said my piece before, but it bears repeating: If you are going to offer a Cryptographically Secure Pseudo-Random Number Generator feature, you need it to be secure first and foremost. An E_ERROR satisfies this requirement (it fails closed), but it's a horrible UX decision. There's an old trope that security and usability are opposites. This isn't necessarily true. I understand that some of the Internals contributors are allergic to special cases. There's some validity to wanting the language to be predictable and consistent across the board, because that might be a UX concern in and of itself. (What do you mean this one function has to be wrapped in try-catch blocks when the others can be prefixed with @ to silence errors? I'm telling PHPSadness!) However, there's already a precedent with a core function throwing a Throwable (i.e. intdiv()), so making a special case for random_bytes() and random_int() doesn't introduce an unprecedented inconsistency. My priorities can be summed up as follows: 1. Don't fail open. 2. Don't make developers want to avoid a secure RNG like the plague. 3. Although it hasn't come up yet: Don't scare or mislead developers when documenting these features. Or in other words: Security >= User Friendly > Consistency with the rest of the language features Your priorities might be different. That's okay, monocultures lead to fragility. But the CSPRNG is a security feature and security should come first. Any deviation from this priority, in the context of a security feature, is a high caliber foot-bullet. I strongly recommend anyone who argues against Exceptions consider how their proposal will affect security and the adoption of the new API in their response. I'm open to change and being proven wrong (i.e. with Errors not meaning E_ERROR earlier in this thread), but don't cripple a security feature because "I want consistency at any cost." 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
