Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99898 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44462 invoked from network); 18 Jul 2017 13:57:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jul 2017 13:57:25 -0000 Authentication-Results: pb1.pair.com smtp.mail=f.bosch@genkgo.nl; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=f.bosch@genkgo.nl; sender-id=pass Received-SPF: pass (pb1.pair.com: domain genkgo.nl designates 46.21.156.38 as permitted sender) X-PHP-List-Original-Sender: f.bosch@genkgo.nl X-Host-Fingerprint: 46.21.156.38 mail.genkgo.net Received: from [46.21.156.38] ([46.21.156.38:41539] helo=mail.genkgo.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5E/28-02884-3C31E695 for ; Tue, 18 Jul 2017 09:57:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=genkgo.nl; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References :Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wWuBb+QKCyQalGvDUSC4KkgpeThmVHyHpGIf6wjn7wo=; b=pzZnI4FlO1qLXMTz6BQySLkJhv NGyOMwuiwtrQUIGl6ZmRlobEF0od37Kca0/bEgg3PHMcHmcqnAOuiojBhy1fVwt15uyJVUQph5koN WMXJ/B9NhXsVLUYyTT6qntVL0GeWru02DXVHYEEixSQEM1Fo7Smy9V7xJAg6Mb20RMb6V0oNCvoOj dNTsxcR+CaRAwZZtAfsylmD45x87hxng+/JjEwYtaYrknlvLWp7qEXD5dJA8rhQx5BhzUjfiQ2sEy mC57ghcAi5sDnrqivBsfQf3LROR+BT78RpYJtcg1j9NHMP6n20o+2DEVlRU0DpU5GGY15r9E0bA2q 8/AXsSIA==; Received: from [188.213.225.106] (helo=[192.168.15.254]) by mail.genkgo.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dXT04-0007Uv-2b; Tue, 18 Jul 2017 15:57:20 +0200 To: Marco Pivetta Cc: PHP Internals List References: <14052ebf-efea-cb43-39e0-bdc30e493ff3@genkgo.nl> Message-ID: <26c3127e-14a8-e5c2-599e-ee629aef511a@genkgo.nl> Date: Tue, 18 Jul 2017 15:57:19 +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: Content-Type: multipart/alternative; boundary="------------65EA6D5AE598F83D590BE80A" Content-Language: nl-NL X-Antivirus-Scanner: Clean mail though you should still use an Antivirus Subject: Re: [PHP-DEV] [RFC] samesite cookie implementation From: f.bosch@genkgo.nl (Frederik Bosch | Genkgo) --------------65EA6D5AE598F83D590BE80A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Marco, Great feedback. I have to think about it, but your concerns are valid for sure. The RFC is, however, broader then only setcookie and setrawcookie. How about session_set/get_cookie_params? Would you be able to accept the RFC if samesite would only be added to session? Why or why not? Frederik On 18-07-17 15:45, Marco Pivetta wrote: > Hey Andrey, > On Mon, Jul 17, 2017 at 11:11 PM, Frederik Bosch | Genkgo > > 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?id=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. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > --------------65EA6D5AE598F83D590BE80A--