Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91640
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.53 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAFMT4NoHEJNu5HX_ciWvivPMEtTgX681DK544vwQMVMKNNUWaA@mail.gmail.com>
References: <CAGa2bXZqCd4g5BwzRxWsVw351G_o1+AkhGq3cdyKhUW39rm4Tg@mail.gmail.com>
 <CAFMT4NoHEJNu5HX_ciWvivPMEtTgX681DK544vwQMVMKNNUWaA@mail.gmail.com>
Date: Sat, 12 Mar 2016 09:24:27 +0900
Message-ID: <CAGa2bXbKdw0rHyU5gPq0rhosBs+KJkzM=QYn8fyHPRB-O3+o=A@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][VOTE] Precise session management
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

Hi Levi,

On Sat, Mar 12, 2016 at 1:50 AM, Levi Morrison <levim@php.net> wrote:
> On Wed, Mar 9, 2016 at 2:14 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>> The RFC is
>> https://wiki.php.net/rfc/precise_session_management
>> The PR is
>> https://github.com/php/php-src/pull/1734
>>
>> I suppose almost all questions and discussion is finished, but
>> if you have any, please comment/ask.
>
> After talking to a few people I still don't understand this RFC. That
> makes me nervous. I think partly this is due to the many issues trying
> to be solved inside this one RFC. To be frank, a large part of it also
> comes from the fact that the phrasing is difficult to understand.
>
> In summary, I can't feel good about voting yes on this RFC because I
> don't understand it. I've honestly tried, but I don't really get it,
> nor have several other people I have talked to. Additionally there
> appear to be BC breaks though I can't really judge their impact. Given
> that this is a minor release I don't think it's a good idea to break
> BC.
>
> I will wait for someone to respond to this email before voting, but
> unless I am convinced by further discussion I will be voting no.

Thank you for feedback.

The main points of this RFC are
 - Avoid race conditions result in session loss.
 - Make session abuse a lot harder. i.e. More secure than now.

To achieve those 2 objectives, timestamp management is introduced because
 - There is no reliable way to synchronize web server and client
state. i.e. Cookie as well as session ID by transid.
 - There is no reliable way to remove obsolete session by default.
i.e. Probability based GC is not good enough and allows attackers to
steal PHP session forever.

Because there is no way to synchronize server/client and probability
based GC is hardly acceptable, eventually consistent approach is used.

Eventually consistent approach is the same as it is now, but new
session manager does it much precise/stricter way by using timestamps.

Will this explanation help to understand it?

IMHO, this is mandatory change for session module to be more reliable
and secure than now. I hope I explained well reason behind the change.
Normal users don't know risks that this RFC is trying to
resolve/mitigate. Therefore, we are better to release it asap.

BC issue is not severe. Users' test scripts may find behavior changes,
but it does not affect session functionality in apps at all. (It
should not at least, if it does, it's bug)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net