Hi Anthony, > -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Saturday, August 1, 2015 2:34 AM > To: Ferenc Kovacs <tyr...@gmail.com> > Cc: Sammy Kaye Powers <m...@sammyk.me>; internals@lists.php.net; Nikita > Popov <ni...@php.net> > Subject: Re: [PHP-DEV] Core functions throwing exceptions in PHP7 > > Ferenc, > On Jul 31, 2015 6:34 PM, "Ferenc Kovacs" <tyr...@gmail.com> wrote: > > > > > > > > On Tue, Jul 14, 2015 at 11:04 PM, Sammy Kaye Powers <m...@sammyk.me> > wrote: > >> > >> Hello lovely PHP nerds, > >> > >> There are two open PR's for PHP7 to modify the behavior of the CSPRNG's: > >> > >> https://github.com/php/php-src/pull/1397 (main discussion) > >> https://github.com/php/php-src/pull/1398 > >> > >> Currently the random_*() functions will issue a warning and return > >> false > if > >> a good source of random cannot be found. This is a potential security > hole > >> in the event the RNG fails and returns false which gets evaluated as > >> 0 > in a > >> cryptographic context. > >> > >> To prevent this exploit the proposed behavior will throw an Exception > when > >> the RNG fails or certain argument validation fails. This also gives > >> the developer a graceful way to fall back to an alternate CSPRNG. > >> > >> Since the core functions in PHP don't throw Exceptions, there is > >> debate > on > >> whether or not this change should be implemented. Some say the > >> CSPRNG's should get a special pass since they will be relied on for > cryptography. > If > >> we can't throw Exceptions, there were suggestions of raising a fatal > error > >> if the RNG fails. > >> > >> I think the argument can be boiled down to consistency vs security. > >> We'd love to hear your feedback to decide what we should do in this > >> context. > :) > >> > >> Thanks, > >> Sammy Kaye Powers > >> sammyk.me > >> > >> Chicago, IL 60604 > > > > > > I would vote for E_WARNING and return false. > > This can be wrapped in an oop wrapper in userland if somebody prefers > > and > exception but would still keep the procedural style as first class citizen. > > Plus this would be consistent with other security/crypto related > > errors > like mcrypt_encrypt() getting an invalid key/iv > > Nikita, Anthony what do you think? > > Strong -1 on this. > > The consistency point is something to consider, but there are three major > differences between password_* + mcrypt_* and this case. > > First, the majority of mcrypt and password functions are single use. > Meaning they are called once and not inside of loops. Random_int on the other > hand will be used in loops and in direct combination with other functions. > > Second, the target audience is different. Mcrypt targets those that know > something about what they are doing. The api is designed that way. Don't get > me wrong, a lot of users have no idea how to use the APIs properly. But the > api > is designed such that you need to know it well to use it effectively. This is > a > massive fundamental problem with how crypto code was implemented in php. > Things have been changing lately though. Apis are being designed with end > users > in mind. Password_hash was one of these, but others are on their way as well. > In general, the difference is putting the onus of correct usage on the > designer > rather than the implementor. Make it harder to screw up than to do it safe. > > Third and lastly, they were built in different times. Had exceptions been > acceptable when I wrote the password functions, believe me I would have used > them. But they weren't just not an option, they were strictly verboten. Today > things are very different with 7. IMHO an exception is the right way to error > here. The problems Scott raises are too big and have too much potential impact > to just leave to the implementors. > > Instead, let's follow the trend of not handicapping what's possible. But > instead > making it harder to do something wrong than to do it right. > > After all, we are not discussing whether an error is appropriate here. We are > discussing whether to fail in a way that forces the user to admit there was > failure, or fail in a way they they can miss (leading to insecurity)... > If I'm allowed to notice, what is still not being discussed here is how exceptions are to be thrown in functions. Checking the wiki every day anticipating to find a RFC draft, but hopeless :)
There's still no overall understanding where and how Error vs. Exception are to be meant. There is still no point about how to proceed with the legacy code a way not producing a parallel universe of nice vs ugly code. Still no mention which cases are there, which cases would be acceptable and which wouldn’t. Et cetera. There's only an discussion of one case which doesn't build the whole picture. Having at least this in mind, the procedure of how this case is being thrusted appears to be running deficient, while not the main thrust. If functions are supposed to be failing - so be. ATM it could be done PHP5 way, might it want to fail softly or rudely. But due to above, IMHO we're not ready to start throwing exceptions in functions today, so in 7.0. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
