Use a base16 hash for dynamic css/js asset names

The original md5() issue is #723802: convert to sha-256 and hmac from md5 and sha1 → . I strongly disagreed with it at the time and still do, annoying that we're still dealing with the fallout of that 14 years later.

Since then, there is now xxHash support in PHP which is being used in a couple of places in core (including in the asset hash generation itself) but not everywhere consistently yet. We could base16 encode an xxhash and remove the fake cryptography altogether maybe? Would still want the hash salt included in there though I think to ensure the hashes aren't valid across different sites for otherwise identical library combinations.

Was trying to think whether changing the hash generation will cause any problems after deployments but I don't think it will be any more of a problem than a version change on a commonly used library. 📌 Bring back the asset stale file threshold Active would help to smooth that out a bit more, but don't think it's blocking or anything.

The xxHash is an interesting one, I've created a quick 3v4L PHP snippet to showcase the outputs from the various hashing algorithms.

It appears xxh64 already provides a fairly short 16 character hexadecimal output as it's a 64-bit hash, so that seems like the way forward. I'll try putting in a MR for the changes in due course and see if the change breaks anything.

@catch: You wrote the comment I had halfway written before I was distracted onto something else. Yes, we want these algos to be very fast. Moving to cryptographically-secure algos here makes no sense insomuch as I understand the use case.

One extra question though - if Crypt::hasBase64() gets caught in slightly over-greedy nginx rules, then why don't user password reset hashes and similar?

then why don't user password reset hashes and similar?

They probably do as well, but from my use case so far, user resets are rarely done, and not necessarily deterimental to the user experience enough since the user reset hash can be easily regenerated to give a different hash that won't match the questionable URI path, whereas asset hashes appears to always be the same even after a cache clear and can cause the rest of the site to be non-functional or appear broken.

One question I've had is whether we even need to base64 encode the SHA256 hashes in the first place? It's already URL safe as hexadecimals, and base64-ing it doesn't appear to make it more secure than it currently is, it just provides a slightly shorter string.