Re: [VOTE] Secure Session Module Options/Internal by Default

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.