Hi, > -----Original Message----- > From: Anthony Ferrara [mailto:ircmax...@gmail.com] > Sent: Friday, August 21, 2015 3:37 PM > To: Scott Arciszewski <sc...@paragonie.com> > Cc: Pierre Joye <pierre....@gmail.com>; Trevor Suarez <ric...@gmail.com>; > Niklas Keller <m...@kelunik.com>; PHP Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 > > On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski <sc...@paragonie.com> > wrote: > > On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye <pierre....@gmail.com> wrote: > >> On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski <sc...@paragonie.com> > wrote: > >>> On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez <ric...@gmail.com> > wrote: > >>>> Ah, I didn't realize this thread existed. I had just commented on > >>>> the old one, but the point still stands: > >>>> > >>>> PHP 7.0 RC1 was just tagged. > >>>> Shouldn't this be a relatively high priority to fix/decide so we > >>>> don't end up with behavior that can't be fixed until PHP 8.0? > >>>> > >>>> On Mon, Aug 10, 2015 at 6:54 PM Niklas Keller <m...@kelunik.com> wrote: > >>>>> > >>>>> > > >>>>> > Okay, great, we have people on both sides on this discussion. I > >>>>> > hope nobody minds if I sit this part out. > >>>>> > > >>>>> > What specifics need to be discussed? Should somebody set up a > >>>>> > poll? (I don't know how to do that.) > >>>>> > >>>>> > >>>>> You can find information on how to setup a poll in step 6 here: > >>>>> https://wiki.php.net/rfc/howto > >>>>> > >>>>> Regards, Niklas > >>> > >>> I agree that this should be a relatively high priority. I'm not sure > >>> what the next steps would be. (Aside: I still have a PR I need to > >>> write that I've been holding off on until the fate of PHP 7's CSPRNG > >>> feature is determined.) > >>> > >>> Can we reach some sort of consensus on throw new Exception vs throw > new Error? > >> > >> I think the best would be a RFC, not only for the decision itself but > >> also to have a clear view about what will be changed or affected. > >> > >> Cheers, > >> -- > >> Pierre > >> > >> @pierrejoye | http://www.libgd.org > > > > Fine, let's do this: > > > > 1. Violate the feature freeze for this exceptional decision. > > 2. One of the folks in the camp that WANTS an RFC and a drawn out > > formal decision-making process opens it with a poll. > > 3. Give me voting karma. > > > > Let's NOT make the CSPRNG feature fail open. That is an absolutely > > terrible idea. > > My proposal/stance: > > Let's make random_* throw an Exception if it cannot connect to a random > source. And let's have it throw an TypeError if ZPP fails, or Error if min >= > max. > > The first two are consistent with existing exceptions. > > The third (Error if min>max) is where the contention lies. I'm suggesting > Error as > it's consistent with parameter errors in the sense that the type may be > correct, > but the value isn't (hence it's the same kind of error as a parameter error, > just a > different sub-classification. > > MHO is this is too important of a distinction to simply gloss over. > Having it return false (or null) will be a problem, as nobody will perform > the error > checks. And returning $x where `$x == 0` in a security context could be > incredibly > bad. As such, I think the security implications here outweigh nearly all of > the > other concerns about consistency and convention. > > That's my opinion. I'll be happy to make the changes if a RM gives me the > green > light to do so. > The change being proposed was discussed once more in the RM circle and is being seen as inappropriate.
The CSPRNG RFC and the implementation was voted. The change being proposed amends the paradigm of the current language behavior. Currently no effort has been done do discuss and work out the paradigm change. By today's terms, there are other functions which could require throwing instead of returning false for security reasons. Security being over BC was and is even in the patch versions, however how it is handled is related to the hard and deeply internal cases like memory corruption, etc. Having a decision that a return value is something security related has impact to the existing behavior. Having different technical requirements to the congeneric cases on the language level brings inconsistency. Producing inconsistent behaviors by one case, without any evaluation and clear course for other cases, without respecting the votes and code freeze is alarming. The current timeline doesn't allow for a proper solution of this topic in 7.0. The RMs recommendation is that everyone expressing a strong support in this thread for the behavior change either for core functions in general or particularly in the security context stands up for a proper solution in 7.1. If no one believes that a proper solution can exist in 7.1, then an inconsistency shouldn't exist in 7.0, except the community wants it to be so which brings it back to an RFC. With respect to everyone who voted on the original implementation of CSPRNG RFC and everyone else regarding the topic "throwing in the core functions" it should be accepted in the usual ways that are foreseen. Best regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
