Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72789
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZeA2G3APC8YeRSm=CWOepuVFBm=+oEc=zdc=XQ-bu=Nw@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>
Date: Mon, 24 Feb 2014 11:50:31 +0200
Message-ID: <CAPhkiZyACKxs4Fgj=o9JMODmyGEe77B0CSjRmpPaopSYx6NuMg@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 11:31 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>> >> > - Hash used by session may fallback to SHA-1 from SHA-256
>> >>
>> >> What?! Why would that happen?
>> >
>> >
>> > ext/hash could be DL module. There is #if for this case.
>>
>> This is a more serious flaw than the one you're trying to protect
>> against. I'd suggest one of the following:
>>
>>  - Force ext/hash to be dynamically loaded when session wants to use it.
>>  - Not give the ability to disable the extension at all.
>>  - Emit E_WARNING when a user tries to use an unavailable algorithm.
>>
>> Actually, the last one should be done anyway, IMO.
>
>
> OK. Third one seems the one to me, too.
>
>  - 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.

>
> 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.
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?

Cheers,
Andrey.