>
> 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