Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117092
Message-ID: <7527ab0b-bed1-6788-a0ff-e75672054be7@bastelstu.be>
Date: Mon, 21 Feb 2022 12:39:34 +0100
MIME-Version: 1.0
Content-Language: en-US
To: Marco Pivetta <ocramius@gmail.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>,
 PHP Internals List <internals@lists.php.net>
References: <5983302.2649742.1645319015766@email.ionos.com>
 <6238bf00-011e-35cc-d84b-4082b4f05099@gmail.com>
 <497325306.1564942.1645357444018@email.ionos.com>
 <3c6871ca-589d-6812-800c-a3b9ad6bb575@bastelstu.be>
 <CADyq6sLWRfD2DJwRNWmX=s7rbA2Rs+Agu9tsW9mLQbCeJ27vwA@mail.gmail.com>
 <40015164-ac0c-336d-c7d6-c4766d6caff8@gmail.com>
 <CADyq6s+e_Jkwg1UoGS_e23=6FciRB2-d8q_NxkREMt45f=vs8g@mail.gmail.com>
 <b52c5f52-3295-7792-1897-c170bb132331@bastelstu.be>
 <CADyq6sKjgkM2z_MkYypw79E-payfVG4m7hdsbDoLTPnSJMTLhA@mail.gmail.com>
In-Reply-To: <CADyq6sKjgkM2z_MkYypw79E-payfVG4m7hdsbDoLTPnSJMTLhA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] RFC proposal to deprecate crypt()
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 2/21/22 12:12, Marco Pivetta wrote:
>>>> If it's not going to be removed, what's the point of annoying people
>>>> with deprecation warnings (that they would patch out/silence anyway)?
>>>>
>>>
>>> Probably to be removed in `9.0` or `10.0`? Yes, it should be removed at
>>> some point.
>>
>> In contrast to other deprecations (e.g. the utf8_encode/decode currently
>> discussed), deprecating and ultimately removing crypt() results in an
>> actual loss of functionality.
>>
> 
> ...yes? That's the point?
> 

I understand that that's the point. However I agree with Stas that this 
would be a BC break with no practical gain and I articulated the reasons 
why I believe that: If crypt() is what you need, then crypt() is what 
you need and being told that your use-case is invalid is not helping 
you. The function already exists and I assume that it does not require 
(relevant) maintenance effort for PHP maintainers keeping it.

With the same arguments one could deprecate and remove md5() (and 
possibly sha1() as well). It should not be used for passwords, it should 
not be used for signatures and any new use should require *careful* 
review. Nonetheless there are cases where you still need an 
implementation of md5() and then not having md5() is an issue.

If someone proposed the removal of md5() I'd disagree the same.

Best regards
Tim Düsterhus