On Mon, Jul 15, 2024, at 13:20, Gina P. Banyard wrote: > On Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer > <php-internals_nos...@adviesenzo.nl> wrote: > > On 2-7-2024 20:05, Gina P. Banyard wrote: > >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer > >> <php-internals_nos...@adviesenzo.nl> wrote: > >> > >>> * While a number of proposals include an impact analysis (thank you!), a > >>> significant number of the proposals don't. > >>> It would be appreciated if for those proposals which aren't removing > >>> unused/unusable functionality, some sort of impact analysis was added. > >> > >> You will need to clarify which ones you are talking about. > ... snip big ... > > > I also don't agree that there are "more appropriate replacements available". > > The suggested `hash()` replacements for the md5/sha1* functions have the > > exact same functionality, which the RFC considers "incorrect use", so what > > are we actually solving by this deprecation ? Devs not having enough to do > > already ? > > The problem (for open source) with "force-replacing" the uses of > > `md5/sha1*` functions with the `hash` function calls, is that the hash > > extension was not part of PHP core until PHP 7.4, which means that for a > > significant number of open source projects, the replacement is not a > > one-on-one function call replacement, but needs guard code for PHP < 7.4 in > > case the hash extension is not available. > > Reiterating what I said previously, replacing it with the one-to-one > equivalent should only be done if you truly need those specific algorithms. > Otherwise its usage should be reconsidered depending on the requirements and > switched to something "safer". > Hopefully this is clearer now that Tim amended the RFC.
This always gets me. "safer" doesn't have a consistent meaning. For example, if you were to want to create a "content addressable address" using a hash and it needs to fit inside a 128 bit number (such as a GUID), you may be tempted to take SHA-X and just truncate it. However, this biases the resulting numbers, which this bias may be considered unsafe (such as using it in an A/B testing tool). Just because you have a short hash, doesn't make it "unsafe" as longer hashes can also be considered "unsafe." What people usually mean by this is in the context of encryption, and in those cases it is unsafe, but in the context of non-encryption, usage of truncated larger hashes is just as unsafe. — Rob
