Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72682
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <2cb7cac279b9740f6ae011da15088ac9@mail.gmail.com>
References: <CAGa2bXbNU-8HbbRrT5v33NWJPuQKSqxQa7HYDnKdrX07qfndBw@mail.gmail.com>
 <2cb7cac279b9740f6ae011da15088ac9@mail.gmail.com>
Date: Tue, 18 Feb 2014 20:57:23 +0900
Message-ID: <CAGa2bXZ22arMOG9kZN1rh9bH_CRacJWKNRrsSQkpqCsypc1tdQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3ee8e0db5c004f2acfc38
Subject: Re: [PHP-DEV] [VOTE] Secure Session Module Options/Internal by Default
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c3ee8e0db5c004f2acfc38
Content-Type: text/plain; charset=UTF-8

Hi Zeev,

On Tue, Feb 18, 2014 at 8:46 PM, Zeev Suraski <zeev@zend.com> wrote:

> This was previously discussed but I have to agree with Andrey (and maybe
> even go beyond what he said) - the hash_bits change doesn't belong in this
> RFC.  First, it has no security implications and it's not entirely clear
> from the RFC.  Second, I don't feel that the implications of that change
> are
> clear, beyond some mention that "this could not be an issue for almost all
> apps", which personally I don't think is accurate - but either way, we need
> some better analysis here.
>
> From my point of view I don't think a few extra characters per session
> going
> over the wire are worth the potential obscure BC break changing the default
> here will cause with certain session backends and/or apps, and we shouldn't
> include this change in this RFC.  If we want to compact the session id's,
> proposing a change for this default can be done in a separate RFC that
> discusses the pros and cons of doing it, independent of security.
>

I agree. This would be removed. This means vote is closed and reopened
again.

I'm not sure why compiled and php.ini-* default differs now, but it's
irrelevant issue here anyway.

Another thing that I think this RFC is missing is some clearer explanation
> on what kind of apps *don't* work with the proposed changes (most notably
> use_strict_mode=on and cookie_httponly).  Even though my gut is that these
> two proposed changes are good - the RFC should include explanations of the
> code patterns and/or types of apps and/or modules that will be affected by
> this;  "Most apps should not be affected" isn't enough in an RFC IMHO.
>

I'll add explanations and possible side effects. I think of few.


>  Last - the voting period should be at least a week, right now it's 5 (or
> maybe 6, depending on your POV) days.
>

This is mistake. My apologies.

Thank you for your comment.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c3ee8e0db5c004f2acfc38--