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

[Michael M Slusarz]

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.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]