Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75676
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.52 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAAyV7nFva4u-pW0Ago-VpkJ=-RuBvE_fjCg27Wza8_T6M0oYHA@mail.gmail.com>
References: <CAGa2bXYP4L-EVjqiTvrOjbiRvzQJ7zyTQyu78O1AEEkk7nwEhQ@mail.gmail.com>
 <CAESVnVqBxo0VCYM_4V4_KzrD1+-F-0ipumrr_a=mAwaYje10Og@mail.gmail.com>
 <CAGa2bXa48gEEcE_DWE27B3UHD0Yi12bFVZsx-9t_anHunkj5Dg@mail.gmail.com>
 <CAHMUw2FLW06ABT=1RoH2gMuM7HbGDdSnLzxqfv8wNVp0rzfw+Q@mail.gmail.com>
 <CAGa2bXZF5sznggoYRFTtngO32b60NVG=6KqUBDB3guGb7_8oMA@mail.gmail.com>
 <CAHMUw2GyQOevKfZXuyd7S-PPUnShVVeoRvZNHK3q9w1yEe1wow@mail.gmail.com>
 <CADajX4C9sip=57QGaacZVq9cmAFhH6CJWpvSSjB7c921TGsJMQ@mail.gmail.com> <CAAyV7nFva4u-pW0Ago-VpkJ=-RuBvE_fjCg27Wza8_T6M0oYHA@mail.gmail.com>
Date: Fri, 18 Jul 2014 06:12:14 +0900
Message-ID: <CAGa2bXYkdBjoSpDJekPq=hxbty7GexkjyJnPNpH4vM4+v-v64Q@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Adam Harvey <aharvey@php.net>, Tjerk Meesters <tjerk.meesters@gmail.com>, 
	Sara Golemon <pollita@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11345cc2b9aa9d04fe6a1a95
Subject: Re: [PHP-DEV] crypt() BC issue
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11345cc2b9aa9d04fe6a1a95
Content-Type: text/plain; charset=UTF-8

Hi all,

On Fri, Jul 18, 2014 at 4:38 AM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> We internalized the algorithms in 5.3.2 at least partially because the
> system provided libraries were inconsistent at best (hence why many
> but not all 5.2 systems don't support bcrypt, it depended on the build
> of libcrypt you linked against).
>
> Please don't make us re-live this inconsistency... Especially when it
> won't really solve the problem.
>

OK for me. I suggested to close the bug as 'wont fix' in first place.


> Regarding password_verify() accepting crypt(), I consider it an
> implementation detail that it works. I know the RFC specifies it, but
> it specifies it not as a conceptual fact (that it will always be no
> more than a reason to be there), but more as an explanation for what
> it's currently doing. I would not rely on that fact. It may work
> today. It may work tomorrow, but it shouldn't be documented as such
> (as it's the complement of password_hash(), not the complement of
> crypt()).
>
> > As far as I'm aware, the only reason for not marking crypt()
> > E_DEPRECATED right now is for compatibility with external systems, and
> > as far as those go, changing a default won't effect anything.
>
> I want to reinforce that point, because it's spot on the money:
>
> I think crypt should live on. password_hash should be the way new
> systems are built, sure. But as you mention external systems, crypt
> should be a standard way of interacting with them (heck, that's what
> the lib was designed for). It shouldn't be a "if you're not using
> password_hash(), you're doing it wrong". It's "password_hash() should
> solve the majority of use-cases, but if you have a different need,
> there are other options".
>

I agree. crypt() should be available as normal function.

Anthony, do you have suggestion for removing 72 char restriction of
PASSWORD_BCRYPT?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11345cc2b9aa9d04fe6a1a95--