Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72794
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.176 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 15:40:30 +0200
Message-ID: <CAPhkiZzZy66FZMR20-x4we7_kvxq-SAxWMifgsdyu2tQ5iSwmA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] Secure Session Module Options/Internal by Default
From: narf@devilix.net (Andrey Andreev)

On Mon, Feb 24, 2014 at 12:00 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> 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 :)

Well, I'm glad we finally sorted it out.
Although this was all my personal input, somebody else might disagree
on the non-disableable ext/hash. :)

Cheers,
Andrey.