[12.x] Replace md5 with much faster xxhash

[GrahamCampbell]

In particular, this may make a noticeable difference for the etag content hashing. md5 doesn't really have a purpose in 2024: xxh128 is much faster and produces the same size hash as md5.

[hafezdivandari]

What about File::hash()?

• framework/src/Illuminate/Support/Facades/File.php

  Line 14 in 8ca1b5b

  * @method static string hash(string $path, string $algorithm = 'md5')

• framework/src/Illuminate/Filesystem/Filesystem.php

  Line 189 in 8ca1b5b

  public function hash($path, $algorithm = 'md5')

hash_file instead of md5_file?

• framework/src/Illuminate/Filesystem/Filesystem.php

  Lines 544 to 549 in 8ca1b5b

  	public function hasSameHash($firstFile, $secondFile)
  	{
  	$hash = @md5_file($firstFile);
  	return $hash && hash_equals($hash, (string) @md5_file($secondFile));
  	}

• framework/src/Illuminate/Foundation/Vite.php

  Line 765 in 8ca1b5b

  return md5_file($path) ?: null;

[GrahamCampbell]

No, that is intentionally omitted, and should not be changed.

[timacdonald]

We would need to note in the upgrade guide that on the first deploy of an upgraded Laravel 12 app it will reset active rate limiters.

Could be important for applications. It could allow unexpected behaviour within the application if you are using rate limiters to restict business logic, e.g., you can only create 10 invoices per month.

[GrahamCampbell]

Alternatively, I could also revert that portion of this PR, if we don't want this upgrading step.

[timacdonald]

FWIW we already use xxh128 in a few places within the framework related to view hashing.

framework/src/Illuminate/View/Compilers/Compiler.php

Line 85 in 8ca1b5b

return $this->cachePath.'/'.hash('xxh128', 'v2'.Str::after($path, $this->basePath)).'.'.$this->compiledExtension;

framework/src/Illuminate/View/Component.php

Line 201 in 8ca1b5b

if (! is_file($viewFile = $directory.'/'.hash('xxh128', $contents).'.blade.php')) {

framework/src/Illuminate/View/Concerns/ManagesLayouts.php

Line 181 in 8ca1b5b

static::$parentPlaceholder[$section] = '##parent-placeholder-'.hash('xxh128', $salt.$section).'##';

framework/src/Illuminate/View/Compilers/Concerns/CompilesComponents.php

Line 52 in 8ca1b5b

static::$componentHashStack[] = $hash = hash('xxh128', $component);

[taylorotwell]

Agree with @timacdonald we probably only want to do this where it isn't "breaking" in the sense of resetting rate limiters, etc.

[valorin]

I like the idea of swapping to a more efficient hash. Also gets rid of more uses of MD5! 😁

One idea to avoid the breaking change issue is to define the hashing algo in a config file.

Both algos can be used through hash($algo, ...), so it would be trivial to swap between the two by changing the config value without making the code any more complicated. The next major release could default to xxh128, with an upgrade guide step to change back to md5 if your application relies on cache, rate limiters, etc, across upgrades.

[imanghafoori1]

The next major release could default to xxh128, with an upgrade guide step to change back to md5 if your application relies on cache, rate limiters, etc, across upgrades.

Maybe, It is better to default to md5 in source code like this config('app.hash_algo', md5); and add HASH_ALGO=xxh128 to .env.example in laravel/laravel, So upgraders from v11 do not break without noticing anything and installers v12 from scratch also get the performance benefit without noticing anything.

[GrahamCampbell]

There is negligible performance benefit for the choice of hashing algorithm for the cache key for throttling. The cost of reading the config and checking it will be more than the performance gain of changing the algorithm for hashing like 10 bytes of data.

[GrahamCampbell]

OK, I've rolled back the rate limiter change. I think the etag change is low impact and is the place in this PR where we will see the main performance benefit. I think we should note this change in the upgrading guide.