On Fri, Aug 21, 2015 at 10:16 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
>
> Pierre
>
> On Aug 21, 2015 22:01, "Pierre Joye" <pierre.php@gmail.com> wrote:
> >
> > On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> > > Anatol,
> > >
> > > On Aug 21, 2015 8:10 PM, "Anatol Belski" <anatol.php@belski.net> wrote:
> > >>
> > >> Hi,
> > >>
> > >> > -----Original Message-----
> > >> > From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> > >> > Sent: Friday, August 21, 2015 3:37 PM
> > >> > To: Scott Arciszewski <scott@paragonie.com>
> > >> > Cc: Pierre Joye <pierre.php@gmail.com>; Trevor Suarez
> > >> > <rican7@gmail.com>;
> > >> > Niklas Keller <me@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 <scott@paragonie.com>
> > >> > wrote:
> > >> > > On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye <pierre.php@gmail.com>
> > >> > > wrote:
> > >> > >> On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski
> > >> > >> <scott@paragonie.com>
> > >> > wrote:
> > >> > >>> On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez <rican7@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 <me@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.
> > >
> > > 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.
>
> If that's what it will take I will happily draft one tomorrow morning. But if the RMs are against it, I will respect that as well. Hence the dilemma.
>
> Anthony
For the sake of compatibility, I'll make the necessary changes to
random_compat tonight.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
>
> Pierre
>
> On Aug 21, 2015 22:01, "Pierre Joye" <pierre.php@gmail.com> wrote:
> >
> > On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> > > Anatol,
> > >
> > > On Aug 21, 2015 8:10 PM, "Anatol Belski" <anatol.php@belski.net> wrote:
> > >>
> > >> Hi,
> > >>
> > >> > -----Original Message-----
> > >> > From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> > >> > Sent: Friday, August 21, 2015 3:37 PM
> > >> > To: Scott Arciszewski <scott@paragonie.com>
> > >> > Cc: Pierre Joye <pierre.php@gmail.com>; Trevor Suarez
> > >> > <rican7@gmail.com>;
> > >> > Niklas Keller <me@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 <scott@paragonie.com>
> > >> > wrote:
> > >> > > On Fri, Aug 21, 2015 at 3:52 AM, Pierre Joye <pierre.php@gmail.com>
> > >> > > wrote:
> > >> > >> On Fri, Aug 21, 2015 at 9:38 AM, Scott Arciszewski
> > >> > >> <scott@paragonie.com>
> > >> > wrote:
> > >> > >>> On Wed, Aug 19, 2015 at 11:36 AM, Trevor Suarez <rican7@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 <me@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.
> > >
> > > 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.
>
> If that's what it will take I will happily draft one tomorrow morning. But if the RMs are against it, I will respect that as well. Hence the dilemma.
>
> Anthony
For the sake of compatibility, I'll make the necessary changes to
random_compat tonight.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php