On 07/26/2015 01:36 PM, Jakub Kubíček wrote:
> Hi Larry!
>
> 2015-07-26 1:29 GMT+02:00 Larry Garfield <larry@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
> Hi Larry!
>
> 2015-07-26 1:29 GMT+02:00 Larry Garfield <larry@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