Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:87849 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 10410 invoked from network); 22 Aug 2015 00:10:49 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Aug 2015 00:10:49 -0000 Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:39492] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 50/D2-19109-10EB7D55 for ; Fri, 21 Aug 2015 20:10:41 -0400 Received: by h1123647.serverkompetenz.net (Postfix, from userid 1006) id 12D0B23D6299; Sat, 22 Aug 2015 02:10:37 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on h1123647.serverkompetenz.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.5 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=unavailable version=3.3.2 Received: from w530phpdev (p579F3462.dip0.t-ipconnect.de [87.159.52.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by h1123647.serverkompetenz.net (Postfix) with ESMTPSA id 1392D23D6003; Sat, 22 Aug 2015 02:10:35 +0200 (CEST) To: "'Anthony Ferrara'" , "'Scott Arciszewski'" Cc: "'Pierre Joye'" , "'Trevor Suarez'" , "'Niklas Keller'" , "'PHP Internals'" References: <99CE9AAF-E6E9-4D37-B462-E4A63139EAFB@icicle.io> In-Reply-To: Date: Sat, 22 Aug 2015 02:10:42 +0200 Message-ID: <03af01d0dc6e$fe3a20c0$faae6240$@belski.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJC3r66slA4OrIZzeKRJP+F1q+sPAHl0YfMAgPjk1wCP9s7nQJwneruAZT4VZ4CM9u6CwLzisAjAagrhIUCj+BP1QK8KAeHAkruzpacbjqDkA== Content-Language: en-us Subject: RE: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7 From: anatol.php@belski.net ("Anatol Belski") 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 >=20 > 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. >=20 > My proposal/stance: >=20 > 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 >=3D max. >=20 > The first two are consistent with existing exceptions. >=20 > 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. >=20 > 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 =3D=3D 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. >=20 > That's my opinion. I'll be happy to make the changes if a RM gives me = the green > light to do so. >=20 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.=20 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.=20 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