On Mon, Feb 21, 2022 at 12:39 PM Tim Düsterhus <t...@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/
