[PHP-DEV] Getting rid of PHP_Incomplete_Class and "unserialize_callback_func"

2018-08-06 Thread Nicolas Grekas
Hello,

I recently submitted https://bugs.php.net/76681: Make unserialize() handle
a new "callback" option entry

The full story is that I'd like a way to get rid of any
PHP_Incomplete_Class in my code.
The way to do it currently is to change the "unserialize_callback_func" ini
setting at runtime and define a throwing callable. But this feels like bad
design...

Do we want a better way to do it?

Note that this should also apply to nested calls to unserialize (since the
Serializable interface encourages doing so.)

Nicolas


[PHP-DEV] Deprecations for PHP 7.4, preparing named args

2018-08-06 Thread Nicolas Grekas
Hello,

I was reading https://wiki.php.net/rfc/named_params again. Named args would
be great for 8.x.

Following https://wiki.php.net/rfc/deprecations_php_7_4, would it make
sense to deprecate calling `call_user_func_array` with associative arrays,
so that it can be made to work with named args in 8.0? Another option would
be to deprecate `call_user_func_array` altogether and recommend using the
splat operator instead. WDYT?

The named params RFC also tells about "Signature validation allows changing
parameter names", adding a requirement to keep the same parameter name in
child classes. Should this requirement be added to 7.4 with a deprecation
notice?

Are there other things we should deprecate to make room for named args?

Just throwing the ideas so we don't forget considering them, thanks for
reading.

Nicolas


Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

2018-08-06 Thread Yasuo Ohgaki
On Mon, Aug 6, 2018 at 5:53 PM Yasuo Ohgaki  wrote:

>
>
> On Mon, Jul 30, 2018 at 6:51 PM Andrey Andreev  wrote:
>
>> On Mon, Jul 30, 2018 at 5:46 AM, Yasuo Ohgaki  wrote:
>> > On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev 
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki 
>> wrote:
>> >> >
>> >> > One thing regarding implementation.
>> >> > Since the internet RFC has only 2 values for "samesite", the
>> parameter
>> >> > can
>> >> > be
>> >> > bool rather than string so that users can avoid "broken security by a
>> >> > typo".
>> >> > If "samesite" has more than 2 values, the INI handler can be changed
>> so
>> >> > that
>> >> > it can
>> >> > handle both bool and string parameters.
>> >> >
>> >>
>> >> The attribute has 2 possible values, but those are 2 different modes
>> >> of operation *when enabled*, not 2 states in total. It doesn't fit in
>> >> a boolean, and even if it did it wouldn't be forward-compatible that
>> >> way.
>> >
>> >
>> > What do you mean by "those are 2 different modes
>> > of operation *when enabled*, not 2 states in total. "?
>> >
>> > samesite-value = "Strict" / "Lax"
>> >
>> > Flag is flag. It does not matter if it is used as combined values.
>> >
>> > An INI value can be bool and string/etc. Even when 3rd value is added,
>> it
>> > can
>> > be supported. Such INIs exist in PHP already.
>> >
>>
>> A boolean makes sense for Secure and HTTPonly, where the flag either
>> exists or not. That's not what we have here, as SameSite=Lax is not
>> the same thing as not having SameSite at all.
>>
>> bool(false) may make sense as an Off switch, yes, but that's not what
>> you suggested ...
>>
>
>
> Bool actually have 3 values.
>

Simple INI handler can do this, precisely.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Re: [PHP-DEV] [VOTE] Same Site Cookie RFC

2018-08-06 Thread Yasuo Ohgaki
On Mon, Jul 30, 2018 at 6:51 PM Andrey Andreev  wrote:

> On Mon, Jul 30, 2018 at 5:46 AM, Yasuo Ohgaki  wrote:
> > On Sun, Jul 29, 2018 at 9:27 PM Andrey Andreev  wrote:
> >>
> >> Hi,
> >>
> >> On Sun, Jul 29, 2018 at 7:22 AM, Yasuo Ohgaki 
> wrote:
> >> >
> >> > One thing regarding implementation.
> >> > Since the internet RFC has only 2 values for "samesite", the parameter
> >> > can
> >> > be
> >> > bool rather than string so that users can avoid "broken security by a
> >> > typo".
> >> > If "samesite" has more than 2 values, the INI handler can be changed
> so
> >> > that
> >> > it can
> >> > handle both bool and string parameters.
> >> >
> >>
> >> The attribute has 2 possible values, but those are 2 different modes
> >> of operation *when enabled*, not 2 states in total. It doesn't fit in
> >> a boolean, and even if it did it wouldn't be forward-compatible that
> >> way.
> >
> >
> > What do you mean by "those are 2 different modes
> > of operation *when enabled*, not 2 states in total. "?
> >
> > samesite-value = "Strict" / "Lax"
> >
> > Flag is flag. It does not matter if it is used as combined values.
> >
> > An INI value can be bool and string/etc. Even when 3rd value is added, it
> > can
> > be supported. Such INIs exist in PHP already.
> >
>
> A boolean makes sense for Secure and HTTPonly, where the flag either
> exists or not. That's not what we have here, as SameSite=Lax is not
> the same thing as not having SameSite at all.
>
> bool(false) may make sense as an Off switch, yes, but that's not what
> you suggested ...
>


Bool actually have 3 values.

true/false/null(empty)

So there isn't issue being bool INI.
It's much secure than string, since current code does not have validation.
i.e. Typo breaks security setting.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net