Re: [RFC] [VOTE] Deprecations for PHP 8.4

> > In regards to hashing, this is likely fine; for now. There still > isn't an arbitrary pre-image attack on md5 (that I'm aware of). Can > you create a random file with a matching hash? Yes, in a few seconds, > on modern hardware. But you cannot yet make it have arbitrary > contents in our lifetime. The NSA probably has something like this > though, but if so, this isn't widely known. The NSA likely owns "Let's Encrypt" and can therefore MitM every TLS site on the internet. > If the problem is that the web is full of bad documentation, find or > write some GOOD documentation. Then, work out how best to signpost > users to that documentation. Deprecating md5() and sha1() does > neither. This. I'm not going to quote everything, but I read through the comments from today and would say this: 1) This seems very much like the people in support of these deprecations are trying to push PHP to enforce *policy* on developers, rather than simply providing tools. 2) PHP should provide good documentation, but should not try to force every user to do something "best practice" by renaming functions. 3) If a websever/host updates the PHP version and the code breaks, the last thing a dev is looking for is "what's the best practice to refactor this code". The dev is thinking, "our site is down, the boss/client is angry, what's the fastest band-aid I can slap on this to get the site up again". Thus: Provide tools, not policy. Provide good documentation. -- Nick