On 07/26/2015 01:36 PM, Jakub Kubíček wrote:
Hi Larry!

2015-07-26 1:29 GMT+02:00 Larry Garfield <la...@garfieldtech.com>:
Another point here is that 0 is a perfectly legitimate random number in many
cases, so callers would need to do a === check, not just a boolean check.
What "boolean check" are you talkin' about? I've never seen a code
using e.g. strpos() like follows:

<?php

if(!is_bool($pos = strpos('foobar', 'baz'))) {
     // we are correct, use $pos' value somewhere
} else {
     // strpos() produced a boolean, thus no 'baz' found in 'foobar'
}

?>

Rather it is most frequently being done like below:

<?php

if(FALSE !== $pos = strpos('foobar', 'baz')) {
     // we are correct, use $pos' value somewhere
} else {
     // strpos() produced a boolean, thus no 'baz' found in 'foobar'
}

?>

I think in both cases you do a kind of "boolean check".

Yes, I am referring to the second, or variations therein. When using strpos() you need to do a strict check against FALSE (===) to avoid a legit 0 getting misinterpreted. It's also a very commonly forgotten check, especially among newer devs that haven't been burned by it a few times.

My point is that when talking about crypto-related functions, relying on people to get burned a few times and then remember to do a === check against FALSE is a horrible, horrible idea, hence random_int() should fail much harder, as is being suggested here (be that via E_FATAL, exception, error throw, or whatever, as long as the execution does NOT continue). That is, I am agreeing with the proposal to have it die hard. I moderately prefer the throw SecurityError approach as it's not a user-input error but a system config error, but anything that prevents execution from continuing is acceptable security-wise.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to