Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94359
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.158 cause and error)
To: internals@lists.php.net
References: <CAGa2bXaSkozJLLtycujwmHyas9TofRw5s6JzG0EQQvPyU0pxNQ@mail.gmail.com>
 <CAPwsocEffWVhzjNHVA853J+1VfmrhstZ0inihhQVHW=VfLS6Eg@mail.gmail.com>
 <CAPwsocEAvcRoH7FmKHh+eUMd=044Jm8DfwyM_Mb22W4UPvXE=w@mail.gmail.com>
Message-ID: <82f2a6cf-203d-0801-b0bf-b5bedfc9ea60@fischer.name>
Date: Sat, 2 Jul 2016 11:06:42 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0)
 Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <CAPwsocEAvcRoH7FmKHh+eUMd=044Jm8DfwyM_Mb22W4UPvXE=w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam_report: Spam detection software, running on the system "scanner01.home", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Everytime I see a thread mentioning session.use_strict_mode
    I'm wondering why we haven't got around to enable it by default (by means
    of php.ini-development/php.ini-production ). Maybe someone can step forward
    and propose this change for the next version (not 7.1 ...)? [...] 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
  0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                             See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: php.net]
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
Subject: About session.use_strict_mode=0 by default (was: Re: [PHP-DEV]
 [RFC][VOTE] Session ID without hashing)
From: markus@fischer.name (Markus Fischer)

Everytime I see a thread mentioning session.use_strict_mode I'm
wondering why we haven't got around to enable it by default (by means of
php.ini-development/php.ini-production ).

Maybe someone can step forward and propose this change for the next
version (not 7.1 ...)?

It could be documented as a breaking change, refer to the documentation
and finally call it a day :-)

- Markus

On 02.07.16 10:39, Leigh wrote:
> Actually decided to post so
> 
> On Sat, 2 Jul 2016 at 09:16 Leigh <leight@gmail.com> wrote:
> 
>> On Sat, 2 Jul 2016 at 08:36 Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>>> Hi all,
>>>
>>> Currently session module uses obsolete MD5 for session ID. With
>>> CSPRNG, hashing is redundant and needless. It adds hash module
>>> dependency and inefficient (There is no reason to use hash for CSPRNG
>>> generated bytes).
>>>
>>> This proposal cleans up session code by removing hash.
>>>
>>> https://wiki.php.net/rfc/session-id-without-hashing
>>>
>>> I set vote requires 2/3 support.
>>> Please describe the reason why when you against this RFC. Reasons are
>>> important for improvements!
>>>
>>
>>
>  So I have a few issues that span the RFC and the implementation.
> 
> Your RFC states
> 
>> hardcoded default and php.ini-* default values are the same.
> 
> This is not the case.
> 
> Originally the session id length and character set were controlled by
> session.hash_function and/or session.hash_bits_per_character. These
> customisations to configuration will be lost when the user upgrades. You
> have provided a mechanism to control length and charset, but it will
> require new changes to the default settings. This needs to be noted as a
> breaking change.
> 
> Your default for session.sid_length is 48. Up to 7.1 the session id length
> is 32. Your default for session.sid_bits_per_character is 5, up to 7.1 the
> session id uses 4 bits per character. This is a breaking change. (Imagine
> custom session handlers that validate session id character sets, or
> database schemas that will truncate after 32 characters)
> 
> Your patch updates session.use_strict_mode from 0 to 1. I actually don't
> know what this changes, but it's an undocumented change.
> 
> Overall your patch looks very similar to the one I was working on earlier
> in the year, although you appear to have deleted a bunch of tests that you
> could have just updated. You should probably put those back, and update
> them.
>