[PHP-DEV] Re: Early feedback on encrypted session PR

2022-05-17 Thread Mark Randall

On 17/05/2022 21:36, David CARLIER wrote:

I wanted a more general but early feedback on the idea itself
https://github.com/php/php-src/pull/3759



The same question that has already been asked on github:

What is the motivation? What is it meant to achieve?


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



[PHP-DEV] Early feedback on encrypted session PR

2022-05-17 Thread David CARLIER
Hi,

I wanted a more general but early feedback on the idea itself
https://github.com/php/php-src/pull/3759

which is encrypting/decrypting the session on the fly with openssl
(assuming as an improvement it would need a more complex key than the
session id to make it more useful and being configurable).

Regards.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php



Re: [PHP-DEV] [Discussion] Stricter implicit boolean coercions

2022-05-17 Thread Andreas Leathley

On 17.05.22 11:18, Jordi Boggiano wrote:


Thanks for the RFC. I think it's overall a good idea, especially for
cases like "false" => true, and arguably for ints >1/<0, but my gut
feeling is the string=>bool deprecation will lead to a lot of pain.

I definitely see this being done in many places where you expect any
string value to be true and an empty string to be false (without
consideration for the "false" case which is more common in config
style use cases).

I don't know what you could do to improve this without making the RFC
useless though. I wish these things could be tried out in alpha or
even up to early RC builds so we could hopefully get community
feedback in before deciding whether it's worth the pain inflicted or not.


For what its worth, I already found some bugs in the php-src tests where
a function definition was probably changed at some point and a string
was passed to a bool argument which was obviously not intended, or where
a weird value was used for a boolean argument without any apparent
reason. These are the type of unintended coercions I am trying to bring
to light with the RFC.

Using any string as true is also already a bit dangerous: "0" is a
special case string that results to false, which adds a big wrinkle to
the assumption "non-empty string is true".

My main arguments why I think this will not lead to too much unnecessary
pain:

 * Each individual case is easy to fix, the easiest (but also least
   useful) would be to loosly compare a value to true ($value == true)
   instead of directly giving the value to a typed bool
 * bool arguments for internal functions are usually optional, less
   numerous and are much more likely to be set by a constant expression
   than a variable
 * deprecation notices are easy to ignore, and the "disadvantage" of
   the high number of deprecation notices with 8.0 and 8.1 should be
   that most tooling and codebases have gotten more used to dealing
   with them without too much panic

I also added these points to the RFC, because I think there is some
resentment built up for deprecation notices by now, which I can understand.