On Mon, Jul 15, 2024, at 13:20, Gina P. Banyard wrote:
> On Monday, 8 July 2024 at 04:04, Juliette Reinders Folmer
> <[email protected]> wrote:
> > On 2-7-2024 20:05, Gina P. Banyard wrote:
> >> On Tuesday, 2 July 2024 at 10:52, Juliette Reinders Folmer
> >> <[email protected]> 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