Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72795
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZDVz4rc5YbgSDfK_JLL7C_rSn0vd5_zSgREdLz1w=8gw@mail.gmail.com>
References: <CAPhkiZxqmUVR3MhdMUBUuKxxkXndoTdoffbfuQ0oGc5JMvQ8dg@mail.gmail.com>
 <CAGa2bXbBnPQHqBUxe=S3HZtvQHQLdomEM4CEF3F+O0mf4oaktA@mail.gmail.com>
 <CAPhkiZx2sFqDmvdAsxOqqcrN6P09HW7MzFOA0cZbZ_2ruN4izw@mail.gmail.com>
 <CAGa2bXZbiTk_a=aJJY4iUPPaNQbv0yhyU2t6dXv2hAo0atiTdA@mail.gmail.com>
 <5302ABF6.60407@sugarcrm.com> <CAGa2bXbeGGFHJe8t7=9yDpuODWRq9+eVSeQ339j=1gzd4x9wGA@mail.gmail.com>
 <CAPhkiZx_sff8AcucRpHxb=f2w2DxKHt7SrOjQ1oTomrSa0oo-Q@mail.gmail.com>
 <CAGa2bXZVNaYFMR13m8WBv+-S2Yojv5Smg4dxqgQoVmCy3PXoOg@mail.gmail.com>
 <CAPhkiZy=c2a6d+0XuQ2Ypteb7UeA1Ue0gfC2SejKN4m_YpP_eQ@mail.gmail.com>
 <CAGa2bXZeA2G3APC8YeRSm=CWOepuVFBm=+oEc=zdc=XQ-bu=Nw@mail.gmail.com>
 <CAPhkiZyACKxs4Fgj=o9JMODmyGEe77B0CSjRmpPaopSYx6NuMg@mail.gmail.com> <CAGa2bXZDVz4rc5YbgSDfK_JLL7C_rSn0vd5_zSgREdLz1w=8gw@mail.gmail.com>
Date: Mon, 24 Feb 2014 11:05:31 -0300
Message-ID: <CAEf4F9RK+-pBBzbWv4E1xX5yO=1URuj9OGbPp=M=9xhEEdKHaA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Andrey Andreev <narf@devilix.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134a8661ebb7f04f3277899
Subject: Re: [PHP-DEV] [VOTE] Secure Session Module Options/Internal by Default
From: ceceldada@gmail.com (Marcel Araujo)

--001a1134a8661ebb7f04f3277899
Content-Type: text/plain; charset=UTF-8

And about to remove these options, should they be keep in the newest
releases?

; http://php.net/session.bug-compat-42
session.bug_compat_42 = Off

; session value into the global space. session.bug_compat_42 must be
enabled before
; http://php.net/session.bug-compat-warn


2014-02-24 7:00 GMT-03:00 Yasuo Ohgaki <yohgaki@ohgaki.net>:

> Hi Andrey,
>
> On Mon, Feb 24, 2014 at 6:50 PM, Andrey Andreev <narf@devilix.net> wrote:
> >
> >  >  - hash_bits_per_character will be removed from the RFC.
> > >  - Possible issue with ID length change will be documented.
> > >  - "id_length" will be removed. User should use hash index search.
> > >  - Raise error when hash function is not available.
> >
> > I'd be happy with that, yes. :)
> > Although for hash_bits_per_character, I only insisted the RFC to
> > explain that this is a change complementing hash_function.
> >
>
> OK. I'll document it.
>
>  >
> > > Raising error seems not good...
> > > If hash extension is available always, it might be easier for other
> > module,
> > > too.
> > > Do not allow DL/disabling hash extension, perhaps?
> >
> >
> > I see no reason why anybody would want to disable the Hash extension,
> > so sure - I'd remove that choice.
> >
>
> I agree. It will be added to the RFC.
>
>
> > However, silent fallback for stuff like this is never a good thing and
> > somebody might i.e. make a typo while configuring, so why not raise
> > E_WARNING for invalid hash_function regardless?
>
>
> Make sense to me, too.
> I'll make it raise error for any invalid hashes.
>
> Thank you for your help :)
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>



-- 






* Marcel Araujo Analista de SistemasDesenvolvedor
PHP/Zend/JavaScript/jQuery/NodeJSLinux User
#490101http://www.twitter.com/marcelarauj0
<http://www.twitter.com/marcelarauj0> http://blog.marcelaraujo.me
<http://blog.marcelaraujo.me/>http://br.linkedin.com/in/marcelaraujo
<http://br.linkedin.com/in/marcelaraujo> *

--001a1134a8661ebb7f04f3277899--