feat: make sure the APCU autoloader prefix is deterministic when a composer.lock file is available

[drupol]

Hello!

Context PR: #11663

This PR make sure the APCU prefix is deterministic only when 2 conditions are met:

1. When a composer.lock file is available
2. When there's no --apcu-autoloader-prefix command line option set.

It will be predictable by reusing the content-hash key from composer.lock file.

[fredden]

This sounds unsafe. Please can you test and confirm this is safe when classes managed by the application, but auto-loaded by Composer are modified / added / removed? For example, in this repository, dump out an auto-loader (php bin/composer install with the relevant flags), then run some Composer command (eg, composer show) to prime the APCu cache, then modify a PHP file in src/Composer/ (eg, src/Composer/Factory.php) and dump out an auto-loader (php bin/composer install with relevant flags) -- this simulates a "deployment", then run the same Composer command (eg, composer show) and witness if the cached or modified file runs.

composer/composer.json

Lines 76 to 80 in 675e57c

	"autoload": {
	"psr-4": {
	"Composer\\": "src/Composer/"
	}
	},

If you want to make the autoloader prefix deterministic (instead of random as it currently is), then you'll need to ensure that you're hashing more than just the contents of vendor/, but also taking the autoload/autoload-dev sections in the root into account.

[drupol]

This sounds unsafe.

Can you please develop further? What do you mean and why using that is unsafe?
For example, compared to any other string manually set through --apcu-autoloader-prefix why would this would not be valid?

[fredden]

Unsafe in that I think this may result in running old code from memory (ACPu) when new code has been deployed on disk.

[drupol]

Please can you test and confirm this is safe when classes managed by the application, but auto-loaded by Composer are modified / added / removed? For example, in this repository, dump out an auto-loader (php bin/composer install with the relevant flags), then run some Composer command (eg, composer show) to prime the APCu cache, then modify a PHP file in src/Composer/ (eg, src/Composer/Factory.php) and dump out an auto-loader (php bin/composer install with relevant flags) -- this simulates a "deployment", then run the same Composer command (eg, composer show) and witness if the cached or modified file runs.

So you're asking me to modify a file from vendor/ after running composer install ? This is unlikely to happen in any scenario, why would one do that?

[fredden]

So you're asking me to modify a file from vendor/ after running composer install ? This is unlikely to happen in any scenario, why would one do that?

No, I'm saying that there are files in the project itself other than in vendor/ (eg, src/ or app/ or tests/) which are auto-loaded via Composer. Only the contents of vendor/ are "protected" by the content-hash.

[fredden]

Only the contents of vendor/ are "protected" by the content-hash.

Actually, even this is wrong. The content-hash only changes when (the value of certain keys within) composer.json changes. Running composer update to upgrade packages does not modify the content-hash.

The steps/scenario I described above should also apply to changing package versions via composer update (eg composer update --prefer-lowest).

If you want a deterministic value, I think you'll need to generate one for this use case specifically.

[Seldaek]

IMO if you use --apcu and want reproducible builds then you have to specify a meaningfully-unique prefix yourself. Otherwise it is bound to end up badly if we just reuse the lock hash. By default we do not include the apcu prefix so I think this is acceptable.