[dev] [commits] Horde branch master updated. 0ab877c762ed591254793fdeb8840a27087b0c5e

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>
>>>> Quoting Jan Schneider <jan at horde.org>:
>>>>
>>>>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>>>>
>>>>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>>>>
>>>>>>> commit 2d91444b8cb4a63a67355fcd3eb28af6b497b4c0
>>>>>>> Author: Michael M Slusarz <slusarz at horde.org>
>>>>>>> Date:   Wed Mar 12 02:27:59 2014 -0600
>>>>>>>
>>>>>>> Another place to change hash algorithm
>>>>>>>
>>>>>>> framework/Imap_Client/lib/Horde/Imap/Client/Base.php |    5 ++++-
>>>>>>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>>>>>>
>>>>>>> http://github.com/horde/horde/commit/2d91444b8cb4a63a67355fcd3eb28af6b497b4c0
>>>>>>> http://git.horde.org/horde-git/-/commit/2d91444b8cb4a63a67355fcd3eb28af6b497b4c0
>>>>>>
>>>>>> I have mentioned this before in commit messages ... but MD5 has  
>>>>>> been proven to be inadequate for hashing purposes due to  
>>>>>> collision issues.
>>>>>>
>>>>>> See, e.g.:
>>>>>>
>>>>>> http://www.mscs.dal.ca/~selinger/md5collision/
>>>>>>
>>>>>> I've personally changed code to use either SHA-1 (unfortunately  
>>>>>> much slower than MD5, and larger output, but collision  
>>>>>> resistant and should always be available in PHP) or FNV-1(32  
>>>>>> bit) (only available on PHP 5.4+, faster than MD5, designed  
>>>>>> specifically as non-crpytographic hash, low collision rate).
>>>>>>
>>>>>> Would be better to use FNV-1a than FNV-1, but due to oversight  
>>>>>> this was left out of hash() and my patch to add won't show up  
>>>>>> until PHP 5.6.  Even better would be xxhash, but this would  
>>>>>> require the installation of a PHP module.
>>>>>
>>>>> We should wrap and abstract this into a Horde_Util method, so  
>>>>> the best hashing method available will always be used.
>>>>
>>>> Sure, but what is the use-case?
>>>
>>> All the places where you already added a PHP version check.
>>
>> This doesn't address the 2nd issue below (and doesn't address the  
>> 1st issue either if you are not upgrading PHP major versions).
>>
>> So still not seeing the use-case.
>
> To elaborate: still not seeing the use-case for a generic  
> "best-available" hashing class.  Simply because there are a bunch of  
> variables -- length, cryptographic-strength, existing hash type --  
> that go into this determination that are not easily abstracted.
>
> Maybe if you had a more elaborate Base class/driver system that took  
> into account hash length and/or current hash preference.  But having  
> a generic hash method that you pass in a string and get a value out  
> is not useful IMHO.  And at this point, the overhead is destroying  
> the usefulness.
>
> Maybe a method that lists acceptable hash formats by key size would  
> be useful.  But in the end, the calling code still needs to  
> explicitly make decisions about its hashing use case.
>
> Compare this with Horde_Pack where the output string is ALWAYS  
> useable (at least if you don't remove PHP features) since it  
> contains the compression/serialization format embedded in the  
> output, and the output is not expected to conform to a given length.

Comparison with Horde_Pack is actually a good idea.

Obviously such a hashing method/class cannot be used where hashes must  
persist and being recreated/rechecked on a regular basis. In any other  
cases, like cache keys, the worst can happen if the hashing method  
changes, is that a cache is invalidated and needs to be propagated  
again. For in-session hashes, worst case is users having to  
re-authenticate. Both is true if Horde_Pack is using a different  
method too, as long as Horde_Pack is used under such circumstances at  
all. Storing the pack method doesn't help if the packing extension is  
removed for some reason.
Length shouldn't be a problem either as client has to intentionally  
opt into using this hash method and can adapt storage fields  
accordingly.

I'm not strongly advocating for creating such a method, but seeing a  
lot of identical or similar PHP version comparisons sounds like  
screaming for some abstraction/shortcut. Just thinking.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject