Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117093
MIME-Version: 1.0
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>
 <7527ab0b-bed1-6788-a0ff-e75672054be7@bastelstu.be>
In-Reply-To: <7527ab0b-bed1-6788-a0ff-e75672054be7@bastelstu.be>
Date: Mon, 21 Feb 2022 12:49:01 +0100
Message-ID: <CADyq6s+0-tWjLbMz5k-DyJ0UpQtkw5GYiUJaQsd7awGmLdRpxQ@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000038c21b05d885d2ca"
Subject: Re: [PHP-DEV] RFC proposal to deprecate crypt()
From: ocramius@gmail.com (Marco Pivetta)

--00000000000038c21b05d885d2ca
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 21, 2022 at 12:39 PM Tim D=C3=BCsterhus <tim@bastelstu.be> wrot=
e:

> 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 current=
ly
> >> 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.
>

Not a maintenance effort exercise, but a user education exercise.
Users need to stop using `crypt()`, because it just has to stop, period.
They have a period of time to migrate away from it, and then they will get
a hard crash when it's gone-gone-gone, which is **OK**.

In addition to that, end-users of PHP-SRC are not paying customers to the
php foundation, and their systems will keep rotting until they will finally
have to touch them: it would be a different story if there was a LTS
contract in place, but that's not how OSS works.

They can also polyfill it with whatever crazy and broken contraption works
for them, as long as they take the irresponsible security decision upon
themselves.

Calibrated code and feature removal is part of the software maintenance
process, and it has more effects than just code size increase.



> 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.
>

As mentioned elsewhere in the mail thread, `crypt()` is not designed for
fast hashing, and is in fact slow by design.
MD5 and SHA1 still have a place, compared to that, as they are not designed
solely for password hashing.

This is part of "calibrated code and feature removal" from above.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.io/

--00000000000038c21b05d885d2ca--