Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99897
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender)
To: internals@lists.php.net
References: <14052ebf-efea-cb43-39e0-bdc30e493ff3@genkgo.nl>
 <CADyq6s+mNc9AwdM-5_6AXez_K-UTbOFYsviVgYgLnK9moM3GwA@mail.gmail.com>
Message-ID: <2b801df9-682a-5013-3fd8-d420212c2073@rhsoft.net>
Date: Tue, 18 Jul 2017 15:50:06 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CADyq6s+mNc9AwdM-5_6AXez_K-UTbOFYsviVgYgLnK9moM3GwA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: de-CH
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] samesite cookie implementation
From: lists@rhsoft.net ("lists@rhsoft.net")


Am 18.07.2017 um 15:45 schrieb Marco Pivetta:
> Hey Andrey,
> On Mon, Jul 17, 2017 at 11:11 PM, Frederik Bosch | Genkgo <f.bosch@genkgo.nl
>> wrote:
> 
>> LS,
>>
>> Today I finished writing the RFC for implementing same site cookies in
>> PHP, https://wiki.php.net/rfc/same-site-cookie. I am happy to receive
>> your remarks on the proposal, and improve when necessary.
>>
>> For those (only) interested in code, have a look at PR # 2613:
>> https://github.com/php/php-src/pull/2613.
>>
>> For the record, I am just a messenger in this regard. Someone uploaded a
>> patch for this feature in bug #72230: https://bugs.php.net/bug.php?i
>> d=72230. I just took the opportunity to create a PR and the corresponding
>> RFC. Credits for the code go to xistence at 0x90 dot nl.
>>
>> Hopefully, the samesite cookie flag will become a feature of the PHP
>> language through this RFC!
> 
> The current `setcookie` method has 7 parameters, of which 6 are optional.
> This is already a mess, as any default value change introduced for either
> forward-compliance or security issue compliance would result in a BC break.
> 
> This RFC suggests adding even more parameters (URGH), and increasing the
> issue impact.
> 
> I had already expressed this issue in https://wiki.php.net/rfc/openssl_aead,
> which made the `openssl_encrypt` endpoint a mess to deal with: an
> n-dimensional space of optional parameters and possible method behavior
> combinations :-P
> Imagine all the picturesque ways that people could come up with to do
> crypto the wrong way! Fascinating!
> 
> Creating a cookie string in userland is trivial, and the `setcookie`
> functionality should just be left alone and maybe deprecated, IMO
i don't share your optinion, especially talking about 'should be 
deprecated' where i get the feeling some peoples hobby is deprecate 
working things

comparing cookie params with encryption is hopefully just kidding