Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62933
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nGA=1pWLj1G+X1EvoNB0jb4ji6oJ2tGZNwXH=CCae_9wA@mail.gmail.com>
References: <CAAyV7nHZ6Kr7yKF0B-UgauN6eKKxRsqCztP9w9hUzOdiPLHYAw@mail.gmail.com>
	<CADNQb0USW3j7BWEjvDwOdCKoLy3xVJ8eCRjZ610ekKmTL7R9VQ@mail.gmail.com>
	<CAAyV7nGA=1pWLj1G+X1EvoNB0jb4ji6oJ2tGZNwXH=CCae_9wA@mail.gmail.com>
Date: Mon, 10 Sep 2012 22:46:14 +0100
Message-ID: <CADNQb0XRrh21QX1qmqvHpvONRSOARXQpC8XroCFiw2z6F2Px5Q@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [VOTE] Add simplified password hashing API
From: hannes.magnusson@gmail.com (Hannes Magnusson)

On Mon, Sep 10, 2012 at 3:31 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> Hannes,
>
> On Sun, Sep 9, 2012 at 12:23 PM, Hannes Magnusson
> <hannes.magnusson@gmail.com> wrote:
>>
>> On Tue, Sep 4, 2012 at 3:16 PM, Anthony Ferrara <ircmaxell@gmail.com>
>> wrote:
>> > Hello all,
>> >
>> > I'm opening the vote for the simplified password hashing API indicated
>> > here:
>> >
>> > https://wiki.php.net/rfc/password_hash
>> >
>>
>>
>> I like the idea, but I don't understand why this isn't developed as an
>> extension first and then brought into core when it has proven to work
>> and actually simplify things for the user?
>
>
> First off, this has been discussed on the list for literally months.  Why
> wait until the day before voting can end before bringing this up?

So commenting is strictly forbidden during votes?


> Secondly, the main reason for not developing this as an extension is that
> there's really no benefit to it. There are little to no performance gains to
> be had by the C implementation. It can live quite as easily as a PHP
> library.

The benefit is that it can be tested properly and bugs discovered and
ironed out first.
This is not the sort of thing you want to get security bug reports the
day after its released in core.
If your ego is big enough you can guarantee you have tested this
thoroughly and want it to become the recommended way.. You have to be
damn sure you don't fuck it up.

This is exactly the sort of thing that doesn't need to be developed in
the core tree, but can later be merged in once proven successful.


Like I said, I really like the idea, just don't see why it isn't
tested out as an pecl extension first.


>> Especially considering the patch is unfinished.
>
>
> Aside from adding a few more tests, what's unfinished? If you're referring
> to the line in the RFC, I just haven't updated it. The patch has been worked
> on and is in a place where I'd be comfortable submitting it...

The test suite seems very limited, and the code seems to be waiting
for more algorithms to be implemented.

-Hannes