Re: RFC proposal to deprecate crypt()

fwiw i recall a real-world script modifying a linux system's /etc/passwd / /etc/shadow using crypt() because password_hash() couldn't create passwd/shadow-compatible hashes while crypt() could On Mon, 21 Feb 2022 at 12:49, Marco Pivetta <ocramius@gmail.com> wrote: > On Mon, Feb 21, 2022 at 12:39 PM Tim Düsterhus <tim@bastelstu.be> wrote: > > > 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. > > > > 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/ >