Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:60803
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGO76dP6NnvuTZ54eY3RuvkucNfSwW=uJJ707sHxEbt6w@mail.gmail.com>
References: <CAAyV7nHrmZWXUGnzog44kba35Fap38jaCptecRFjessWFHu74w@mail.gmail.com>
	<alpine.DEB.2.02.1206121317310.4834@whisky.home.derickrethans.nl>
	<CAAyV7nGO76dP6NnvuTZ54eY3RuvkucNfSwW=uJJ707sHxEbt6w@mail.gmail.com>
Date: Tue, 12 Jun 2012 16:22:21 +0200
Message-ID: <CAEZPtU7MaOFsUw3VSW-c37SxgokBKDds3RiZ3EKbHXyg=gD6mg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>, Stanislav Malyshev <smalyshev@sugarcrm.com>, 
	David Soria Parra <dsp@php.net>
Cc: Derick Rethans <derick@php.net>, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PBKDF2 addition to OpenSSL - Why Not Hash?
From: pierre.php@gmail.com (Pierre Joye)

hi Anthony,

On Tue, Jun 12, 2012 at 2:45 PM, Anthony Ferrara <ircmaxell@gmail.com> wrot=
e:

>>> I noticed that yesterday a patch was committed to trunk to add PBKDF2
>>> support to the OpenSSL extension. =A0I also noted that in the commit
>>> message, the author indicated that he would have rather added it to
>>> the hash extension, but wasn't able to.
>>
>> Why wasn't he been able to?
>
> I haven't spoken to him, but here's part of his original commit
> message ( https://github.com/php/php-src/commit/f4847efc5d58b3375fa0f3269=
158d5e6ab625c21
> )
>
> 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.
>
>> Doesn't hurt to have it in both of course... So sure.
>
> Ok, I'll add it to my list to forward port it to git and submit the PR...

I am all for having it in hash as well. But yes, it requires more work
that may need additional RFC (changing the API to allow more options
need discussions).

That being said, I am really not in favor of having it yet in 5.4. For
two reasons, first 5.4 is bugs fixes only, no new feature. The second
reason is the whole thing behind this addition. As it looks self
contained, I am not convinced that it is a good choice, or that it is
well tested or designed (api wised) yet. I would prefer to leave it
master for now and see if it is usable and stable for php-next. I have
to ask to revert this addition in the 5.4 branch.

Cheers,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org