Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87854 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23281 invoked from network); 22 Aug 2015 02:01:08 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Aug 2015 02:01:08 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.214.172 mail-ob0-f172.google.com Received: from [209.85.214.172] ([209.85.214.172:34788] helo=mail-ob0-f172.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 92/A4-19109-1E7D7D55 for ; Fri, 21 Aug 2015 22:01:07 -0400 Received: by obbfr1 with SMTP id fr1so72578523obb.1 for ; Fri, 21 Aug 2015 19:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WzjABBeOBHvU2fnNjTs7HtaJJ1NrmV6HtzZJ2pDDzl4=; b=qTodeW7VP/DXo402GE5SbbEDBKADCTJC0LLZFkSBYRgTM94RyhHZhb6dMBqQEpGgDc O5ycvZCzpO7h/HEDaEbMBe2uwGYvJGXadjwrMtQbQHaQqbDV5XbPAMI/y/AVsuqbyA0B 2w5b2EFarwY47aKtAE5gRc3WCL5+39ylMZVuGE5Q9CnvCK5mNH0Hzsak7FNMXaq14Tll ksMNJfAc9WFuZCUmT/rhhuL3aVg0yk1Rw5NPw6ELkB07atma8GtNwxDS+JA2owqzcUmw Q/6P2JR3IH/h/DJOX0gw6Bmc8VUDSFD3L8U83hzbRXDRBEfmAS2jWss5KP5+NGLHHWKA tHJA== MIME-Version: 1.0 X-Received: by 10.60.82.67 with SMTP id g3mr10520431oey.29.1440208862619; Fri, 21 Aug 2015 19:01:02 -0700 (PDT) Received: by 10.202.227.74 with HTTP; Fri, 21 Aug 2015 19:01:02 -0700 (PDT) In-Reply-To: References: <99CE9AAF-E6E9-4D37-B462-E4A63139EAFB@icicle.io> <03af01d0dc6e$fe3a20c0$faae6240$@belski.net> Date: Sat, 22 Aug 2015 09:01:02 +0700 Message-ID: To: Anthony Ferrara Cc: Anatol Belski , Scott Arciszewski , PHP internals , Niklas Keller , Trevor Suarez Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 From: pierre.php@gmail.com (Pierre Joye) On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara wrote: > Anatol, > > On Aug 21, 2015 8:10 PM, "Anatol Belski" wrote: >> >> Hi, >> >> > -----Original Message----- >> > From: Anthony Ferrara [mailto:ircmaxell@gmail.com] >> > Sent: Friday, August 21, 2015 3:37 PM >> > To: Scott Arciszewski >> > Cc: Pierre Joye ; Trevor Suarez >> > ; >> > Niklas Keller ; PHP Internals >> > Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in >> > PHP7 >> > >> > On Fri, Aug 21, 2015 at 6:14 AM, Scott Arciszewski >> > wrote: >> > > On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye >> > > wrote: >> > >> On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski >> > >> >> > wrote: >> > >>> On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez >> > 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 >> > >>>> 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. > > Thank you for sharing your thoughts and being transparent. > > There is one tiny thing I would point out though (which likely makes no > difference). When the random rfc was voted on, engine exceptions was not > accepted. It was a conscious decision by the contributors to not have the > function throw because nothing throws in core. That changed with the later > rfc. Hence why this was reopened. > > The discussion has been biked shedded to death. From before beta1. And > unfortunately it looks like it has just been bike shedded out of contention > for 7.0, which is sad on many levels. > > But this is where we are today. While I think it is less than optimal, so be > it. I do think as well it is better to solve this question for 7.0. It is a kind of big thing even the code changes may be small. Dealing with that for 7.1 and 7.0 will most likely be painful. However we have chosen to have a short timeline to release 7.0. We knew the risks of having such issues to solve. I personally would not mind too much to have a RFC for this case as long as it includes an option to slightly delay 7.0 if necessary. Cheers, -- Pierre @pierrejoye | http://www.libgd.org