Recap - Core functions throwing exceptions in PHP7

10 years ago by Scott Arciszewski — view source — reply

unread

All,

I'd like to move the conversation towards a decision regarding PRs
1397 and 1398. These decisions are blocking random_compat as well as a
security enhancement to random_bytes (merge conflicts are the
worst).

Here's a quick recap

Arguments:

Consistency is more important than security.

random_* should be consistent with the rest of PHP (sans intdiv()).
They should return false and emit an E_WARNING
or E_ERROR warning (the latter is if we want it to fail closed).

It's the responsibility of the developer to know this can
happen and explicitly check for it. Don't throw anything.

Security is more important than consistency.

Placing more responsibility on the developer increases the
likelihood of an implementation error. We should aim for compatible
usability with rand() and mt_rand() for random_int(), which never return
false. For random_int() and random_bytes(), should PHP be unable
to generate a random value (no random device available, file
descriptor exhaustion, etc.) an exception should be thrown. If the
developer wants to handle it gracefully, they can place it in try/catch
blocks (which raising errors make messy). Otherwise, the default
state is to fail closed (i.e. terminate script execution).

Open Questions:

Under what conditions should an Exception be thrown, and which
should throw an Error instead?

Did I miss any?

I'm in favor of throwing something. As for the particulars of what
should be an Exception and what should be an Error, I don't have a
horse in this race. Exceptions already existed and Errors were already
accepted in the Throwable RFC, so I don't believe this warrants
another RFC and putting this decision off until 7.1.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com

10 years ago by Leigh — view source — reply

unread

All,

I'd like to move the conversation towards a decision regarding PRs
1397 and 1398. These decisions are blocking random_compat as well as a
security enhancement to random_bytes (merge conflicts are the
worst).

Here's a quick recap

Arguments:

Consistency is more important than security.

random_* should be consistent with the rest of PHP (sans intdiv()).
They should return false and emit an E_WARNING
or E_ERROR warning (the latter is if we want it to fail closed).

It's the responsibility of the developer to know this can
happen and explicitly check for it. Don't throw anything.

Security is more important than consistency.

Placing more responsibility on the developer increases the
likelihood of an implementation error. We should aim for compatible
usability with rand() and mt_rand() for random_int(), which never return
false. For random_int() and random_bytes(), should PHP be unable
to generate a random value (no random device available, file
descriptor exhaustion, etc.) an exception should be thrown. If the
developer wants to handle it gracefully, they can place it in try/catch
blocks (which raising errors make messy). Otherwise, the default
state is to fail closed (i.e. terminate script execution).

Open Questions:

Under what conditions should an Exception be thrown, and which
should throw an Error instead?

Did I miss any?

I'm in favor of throwing something. As for the particulars of what
should be an Exception and what should be an Error, I don't have a
horse in this race. Exceptions already existed and Errors were already
accepted in the Throwable RFC, so I don't believe this warrants
another RFC and putting this decision off until 7.1.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com

--

We also -need- a consensus in place because we have more security sensitive
features targeting 7.1 and we don't want to have this argument again.

Throwing exception's may not be consistent right now, but it certainly
should be in the future. The transition to a new consistency has to start
somewhere.

10 years ago by Niklas Keller — view source — reply

unread

Scott, could you setup a RFC with a vote, so we can decide?

Nikita proposed those two options:

Error is to be used in cases where an error is attributable to

programmer mistake.

Error signifies a failure condition that the programmer is discouraged

(and unlikely to want) to handle. It should only be dealt with at the top
level.

I'm in favor of 2), I would phrase it like: Error should be used if a
repetitive call with the same input parameters would permanently result
in a failure, otherwise Exception.

Regards, Niklas

10 years ago by Aaron Piotrowski — view source — reply

unread

Scott, could you setup a RFC with a vote, so we can decide?

Nikita proposed those two options:

Error is to be used in cases where an error is attributable to
programmer mistake.

Error signifies a failure condition that the programmer is discouraged
(and unlikely to want) to handle. It should only be dealt with at the top
level.

I'm in favor of 2), I would phrase it like: Error should be used if a
repetitive call with the same input parameters would permanently result
in a failure, otherwise Exception.

Regards, Niklas

I’m in favor of 1), as this was my original intention of the Error branch of
exceptions. Errors should be attributable to a programming mistake that should
be corrected. Exception should be thrown for unexpected conditions that are not
due to programmer error, but instead things like IO or permission errors. I think
this is how exceptions thrown from core functions (and all functions or methods in
extensions) should be organized.

Based on this interpretation, random_int() should throw an Error if $min > $max
and random_bytes() should throw an Error if $length <= 0. random_bytes() and
random_int() should throw an Exception if random data cannot be generated.

Another quote from Nikita’s message to the prior thread:

Another interesting aspect are the zpp calls. Currently these will throw a
warning and return NULL in weak mode and throw a TypeError in strict mode.
I wonder whether we should be using zpp_throw for new functions, so a
TypeError is also thrown in weak mode. Continuing to use the old
warning+NULL behavior was a BC concern, which we don't have for new
functions. The reason why I think this is worth considering, is that if all
other error conditions of a function already throw, then ordinary zpp will
still add one case where a different type is returned on error. This makes
random_int from a function returning int, to a function returning int|null.

I would also be in favor of throwing TypeError from zpp calls in new functions
(and quite frankly, from zpp calls in all functions, including old functions).

Regards,
Aaron Piotrowski

10 years ago by Scott Arciszewski — view source — reply

unread

Scott, could you setup a RFC with a vote, so we can decide?

Nikita proposed those two options:

Error is to be used in cases where an error is attributable to
programmer mistake.

Error signifies a failure condition that the programmer is discouraged
(and unlikely to want) to handle. It should only be dealt with at the top
level.

I'm in favor of 2), I would phrase it like: Error should be used if a
repetitive call with the same input parameters would permanently result in
a failure, otherwise Exception.

Regards, Niklas

Scott, could you setup a RFC with a vote, so we can decide?

Nikita proposed those two options:

Error is to be used in cases where an error is attributable to
programmer mistake.

Error signifies a failure condition that the programmer is discouraged
(and unlikely to want) to handle. It should only be dealt with at the top
level.

I'm in favor of 2), I would phrase it like: Error should be used if a
repetitive call with the same input parameters would permanently result
in a failure, otherwise Exception.

Regards, Niklas

I’m in favor of 1), as this was my original intention of the Error branch of
exceptions. Errors should be attributable to a programming mistake that should
be corrected. Exception should be thrown for unexpected conditions that are not
due to programmer error, but instead things like IO or permission errors. I think
this is how exceptions thrown from core functions (and all functions or methods in
extensions) should be organized.

Based on this interpretation, random_int() should throw an Error if $min > $max
and random_bytes() should throw an Error if $length <= 0. random_bytes() and
random_int() should throw an Exception if random data cannot be generated.

Another quote from Nikita’s message to the prior thread:

Another interesting aspect are the zpp calls. Currently these will throw a
warning and return NULL in weak mode and throw a TypeError in strict mode.
I wonder whether we should be using zpp_throw for new functions, so a
TypeError is also thrown in weak mode. Continuing to use the old
warning+NULL behavior was a BC concern, which we don't have for new
functions. The reason why I think this is worth considering, is that if all
other error conditions of a function already throw, then ordinary zpp will
still add one case where a different type is returned on error. This makes
random_int from a function returning int, to a function returning int|null.

I would also be in favor of throwing TypeError from zpp calls in new functions
(and quite frankly, from zpp calls in all functions, including old functions).

Regards,
Aaron Piotrowski

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.)

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com

10 years ago by Niklas Keller — view source — reply

unread

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

10 years ago by Trevor Suarez — view source — reply

unread

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?

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

10 years ago by Scott Arciszewski — view source — reply

unread

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?

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?

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com

10 years ago by Pierre Joye — view source — reply

unread

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?

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

10 years ago by Scott Arciszewski — view source — reply

unread

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?

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:

Violate the feature freeze for this exceptional decision.
One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.
Give me voting karma.

Let's NOT make the CSPRNG feature fail open. That is an absolutely
terrible idea.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com

10 years ago by Anthony Ferrara — view source — reply

unread

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?

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:

Violate the feature freeze for this exceptional decision.

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

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.

Thanks

Anthony

10 years ago by Andrey Andreev — view source — reply

unread

Hi,

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! Please don't sweep this under the carpet.

Yes, the RFC and release processes are vital, and consistency is
desirable, but neither should be an excuse for what could be a
horrible mistake here.

Cheers,
Andrey.

10 years ago by Rasmus Lerdorf — view source — reply

unread

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.

I don't think anyone would argue those two. It makes sense.

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.

An error on this makes sense to me too and it doesn't seem like much of
an issue to make this change now. But yes, it is the RM's final call.

-Rasmus

10 years ago by Anatol Belski — view source — reply

unread

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 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?

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:

Violate the feature freeze for this exceptional decision.

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

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

10 years ago by Anthony Ferrara — view source — reply

unread

Anatol,

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:

Violate the feature freeze for this exceptional decision.

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

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.

Thank you for the time and for everything you do/are doing for the project.

Anthony

10 years ago by Pierre Joye — view source — reply

unread

Anatol,

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:

Violate the feature freeze for this exceptional decision.

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

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

10 years ago by Anthony Ferrara — view source — reply

unread

Pierre

On Sat, Aug 22, 2015 at 8:43 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:

Anatol,

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:

Violate the feature freeze for this exceptional decision.

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

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

10 years ago by Scott Arciszewski — view source — reply

unread

Pierre

Anatol,

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:

Violate the feature freeze for this exceptional decision.

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

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

10 years ago by Pierre Joye — view source — reply

unread

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.

For what I understand the RMs are not against what it is proposed but
its incompleteness and the fact that it affects the timeline for php

The sooner will benefit from a RFC, making this whole discussion a lot
clearer. The latter is a requirement to change, even slightly,
anything about what we decided for php 7. The RMs role is to ensure we
respect what we decided by RFC, hence the oppositions.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

10 years ago by Anthony Ferrara — view source — reply

unread

Pierre

On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:

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.

For what I understand the RMs are not against what it is proposed but
its incompleteness and the fact that it affects the timeline for php

The sooner will benefit from a RFC, making this whole discussion a lot
clearer. The latter is a requirement to change, even slightly,
anything about what we decided for php 7. The RMs role is to ensure we
respect what we decided by RFC, hence the oppositions.

By convention, it is also to decide which rfcs are applicable for a
specific release. I would like to respect that. If they say no, I won't
waste time and energy on the rfc process as it will be pointless as it
won't affect 7.0. If they say yes, then we can make it quick and as
painless as possible and settle it once and for all.

It bothers me though that it has to come down to this. But that's another
discussion for another day.

Anthony

10 years ago by Pierre Joye — view source — reply

unread

On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:

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.

For what I understand the RMs are not against what it is proposed but
its incompleteness and the fact that it affects the timeline for php

The sooner will benefit from a RFC, making this whole discussion a lot
clearer. The latter is a requirement to change, even slightly,
anything about what we decided for php 7. The RMs role is to ensure we
respect what we decided by RFC, hence the oppositions.

By the way, I would really like to see other voicing their opinion on the
matter, especially those having pushed hard in favour of this timeline.

10 years ago by Nikita Popov — view source — reply

unread

On Sat, Aug 22, 2015 at 2:10 AM, 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:

Violate the feature freeze for this exceptional decision.

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

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.

There has been quite extensive discussion on this topic. Apart from 30
comments on the original PR for this, there are 100 mails across three
topics discussing this issue. As far as I can discern, there was a rather
clear consensus in these discussions to make the error conditions throw
(although this may be confirmation bias speaking).

The only point of contention that was left towards the end of the
discussion, was which exception specifically should be thrown in one of the
cases. This was a bikeshedding concern. All the people who participated in
the Exception vs. Error discussion are okay with either choice here, with
mild preferences going in different directions. You could flip a coin and
nobody would complain about the result. Nobody really cares whether this
exception is green or blue.

I'm honestly surprised at this decision. I had assumed that the question of
whether we throw was already a done matter and we're only talking about the
exception type at this point.

Nikita

10 years ago by Anatol Belski — view source — reply

unread

Hi Nikita,

-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Saturday, August 22, 2015 12:17 PM
To: Anatol Belski anatol.php@belski.net
Cc: Anthony Ferrara ircmaxell@gmail.com; Scott Arciszewski
scott@paragonie.com; 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

There has been quite extensive discussion on this topic. Apart from 30
comments on the original PR for this, there are 100 mails across three topics
discussing this issue. As far as I can discern, there was a rather clear consensus in
these discussions to make the error conditions throw (although this may be
confirmation bias speaking).

The only point of contention that was left towards the end of the discussion,
was which exception specifically should be thrown in one of the cases. This was
a bikeshedding concern. All the people who participated in the Exception vs.
Error discussion are okay with either choice here, with mild preferences going in
different directions. You could flip a coin and nobody would complain about the
result. Nobody really cares whether this exception is green or blue.

I'm honestly surprised at this decision. I had assumed that the question of
whether we throw was already a done matter and we're only talking about the
exception type at this point.

No exact counting, but on github and ML there were probably not more than 20 participants. To compare, alone on the CSPRNG voting 41 persons took part. What is happening is that the "exceptions snow ball" starts to roll, the commendation to have an RFC was expressed earlier and is merely a measure to ensure everyone is involved and the "snow ball" doesn't turn into a "snow bank" at the end. Hopefully the escalation happened lately is good for seeing possible consequences to take shape.

Regards

Anatol

10 years ago by Christoph Becker — view source — reply

unread

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

AIUI, that is not how it is supposed to work. Those who want to change
existing behavior should make a respective RFC, if consensus couldn't be
reached otherwise.

Give me voting karma.

I suggest you apply for a Git account, see http://php.net/git-php.php. :)

--
Christoph M. Becker

10 years ago by Pierre Joye — view source — reply

unread

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

AIUI, that is not how it is supposed to work. Those who want to change
existing behavior should make a respective RFC, if consensus couldn't be
reached otherwise.

Do you mean a change like this can be applied without rfc? If yes, I
disagree.

Give me voting karma.

I suggest you apply for a Git account, see http://php.net/git-php.php.
:)

Ack :)

--
Christoph M. Becker

10 years ago by Christoph Becker — view source — reply

unread

One of the folks in the camp that WANTS an RFC and a drawn out
formal decision-making process opens it with a poll.

AIUI, that is not how it is supposed to work. Those who want to change
existing behavior should make a respective RFC, if consensus couldn't be
reached otherwise.

Do you mean a change like this can be applied without rfc? If yes, I
disagree.

I was not particularly referring to the issue at hand, but rather made a
general statement. In this case (core functions throwing exceptions)
obviously there is no consensus, so an RFC would be appropriate.

--
Christoph M. Becker

10 years ago by Anthony Ferrara — view source — reply

unread

Anatol,

Hi Anthony,

-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Saturday, August 22, 2015 4:44 AM
To: Pierre Joye pierre.php@gmail.com
Cc: Anatol Belski anatol.php@belski.net; Scott Arciszewski
scott@paragonie.com; Niklas Keller me@kelunik.com; Trevor Suarez
rican7@gmail.com; PHP internals internals@lists.php.net
Subject: Re: [PHP-DEV] Recap - Core functions throwing exceptions in PHP7

Pierre

On Sat, Aug 22, 2015 at 9:16 AM, Anthony Ferrara ircmaxell@gmail.com
wrote:

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.

For what I understand the RMs are not against what it is proposed but
its incompleteness and the fact that it affects the timeline for php

The sooner will benefit from a RFC, making this whole discussion a lot
clearer. The latter is a requirement to change, even slightly,
anything about what we decided for php 7. The RMs role is to ensure we
respect what we decided by RFC, hence the oppositions.

By convention, it is also to decide which rfcs are applicable for a specific release.
I would like to respect that. If they say no, I won't waste time and energy on the
rfc process as it will be pointless as it won't affect 7.0. If they say yes, then we
can make it quick and as painless as possible and settle it once and for all.

It bothers me though that it has to come down to this. But that's another
discussion for another day.

Thanks for your constructive responses and deferential conduct.

Looking retrospectively t the RFC votes closing days noted in the wiki

engine exceptions on March 8th

CSPRNG on March 28th

Throwable on June 17th

the engine exceptions and CSPRNG lay quite near in time, so it is obvious CSPRNG implementation couldn't have been changed short before or after the other one as they cross each other so close in time. A notable fact also is that quite a new stuff in Throwable was taken already after release circle start and the point of no accept for the new RFCs. In any case, by the times so much of new functionality was clearly overmuch to digest. And it is still even more of discovery for people not having PHP7 experiences.

For what it matters, a suggestion about a need on a strategy with this matter sounded in the early days of this discussion. Unfortunately it was not taken seriously, which is sad as well. The exact goal of calling for RFC already at that time was to bring all the bike shedding onto a productive path and to avoid a situation like it is now. Actually this argument is nothing else than bike shedding on the times and mindsets, so were not worth to mention. But having not the 1.5 month time lost, we probably wouldn't stand where we stand now.

From what all the bike shedding crystalized, there are at least three main directions to see, when it comes to throw in functions. Please correct me when I'm wrong

security aspect (this discussion)

conversion of fatal errors (touched partially in a PR by Aaron)

ZPP handling (mentioned by Nikita)

These look like they can be handled separately, what they have in common is

definition of Error and Exception use case

further development of the exception hierarchy

Please don't catch me on the above, it is only what could be marked by my mind from the discussions.

From these, either there can be an RFC with a proper solution of one or all the topics spliced with the possible delay of the PHP7 final awareness, or there can be an RFC to include a partial solution being pushed so far and possible inconsistency consequences, or CSPRNG functionality can be deferred until a complete solution, or CSPRNG can be reimplemented as class where exceptions belong to the natural flow, or a good sustainable solution can be offered in 7.1. Any other ideas. From the time line - there are five release slots until final yet. Were it an RFC which is accepted, the change would land in RC3 most likely, that would mean there were yet three release slots till final. Under the condition that the current timeline is held.

From the last stand point discussed with the other RMs, as they seem not to be reachable for a direct discussion most of today - such a change affects long term features and language paradigm, which is the matter of the community competence. There's the 7.0 timeline which is a voted thing, there is a release process document which defines that the votes take place on RFCs directly and not on the mailing lists. The RMs belief is that the suggested change is the exact kind of needing a collective decision. Due to the concerns explained earlier, the timeline RFC and other items seem to be in clash with the change how it is proposed ATM. To undo/change any of those items to pass the suggested change in, another RFC seems to be inevitable. With the hope that the cautions expressed were taken into account it's up to everyone to take actions and make a choice they hold for right.

Anthony, sincere thanks for your activity and open minded handling in this affair.

From what it sounds like, you wouldn't be opposed to an RFC for
getting it into 7.0. Is that what I understood? If so, we'll have
something in draft today.

Thanks for the clarity!

Anthony