On Thu, May 23, 2013 at 10:39 PM, Adam Harvey <ahar...@php.net> wrote:
> On 23 May 2013 13:31, Nikita Popov <nikita....@gmail.com> wrote: > > On Sat, May 18, 2013 at 11:48 AM, Nikita Popov <nikita....@gmail.com> > wrote: > > > >> Hi internals! > >> > >> I just noticed that we added the PBKDF2 algorithm two times in PHP 5.5. > >> Once in the hash extension, once in the OpenSSL extension. > >> > >> The hash_pbkdf2 function was added via this RFC: > >> https://wiki.php.net/rfc/hash_pbkdf2 > >> > >> The openssl_pbkdf2 function probably was not noticed at that time > because > >> it was just commited, but not mentioned anywhere else (NEWS, UPGRADING, > >> etc). Only saw it in vrana's documentation updates just now. The > relevant > >> commit is here: https://github.com/php/php-src/commit/f4847ef > >> > >> It would be nice if we could have only one of those functions. I'm > >> currently tending towards the hash_ variant because of the commit > message > >> of the openssl_ function: > >> > >> > No easy way to put these in the hash extension since we don't really > >> support optional > >> > parameters to certain algorithms. Implemented in openssl for now since > >> it has it already > >> > and is pretty stable. > >> > > >> > Only SHA1 is confirmed to work as an algorithm but openssl has a > >> parameter so it can be > >> > changed in the future. > >> > >> It seems that the author already would have preferred it in the hash > >> extension and that the openssl variant only works with sha1 (or was only > >> tested with it? not sure). > >> > >> Nikita > >> > > > > No more opinions? It would be nice to have this resolved before 5.5, > > otherwise there will be no way back. > > I'm not really convinced this is a problem in practice — hash_pbkdf2() > is likely to be the commonly used one because it doesn't have the > OpenSSL dependency, but it probably doesn't hurt to have the ability > to also call OpenSSL's independent implementation (say, if a bug is > found in one or the other). > > Adam > If a bug is found we fix it. Proving several implementations of the same thing to account for potential bugs isn't a good idea imho. If two functions for the same thing exist people need to wonder about which one of them should be used, and in the worst case decide to use a pattern like "if function1 exists call function1, if function2 exists call function2, etc". Just like nowadays to generate a random string you usually check something like four of five different functions. I think it's preferable to have one and only one function in a default-enabled extension. Nikita
