-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: make sure the APCU autoloader prefix is deterministic when a composer.lock
file is available
#11964
Conversation
914b3bd
to
acbdcb5
Compare
…omposer.lock` file is available
acbdcb5
to
675e57c
Compare
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 ( Lines 76 to 80 in 675e57c
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 |
Can you please develop further? What do you mean and why using that is unsafe? |
Unsafe in that I think this may result in running old code from memory (ACPu) when new code has been deployed on disk. |
So you're asking me to modify a file from |
No, I'm saying that there are files in the project itself other than in |
Actually, even this is wrong. The The steps/scenario I described above should also apply to changing package versions via If you want a deterministic value, I think you'll need to generate one for this use case specifically. |
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. |
Hello!
Context PR: #11663
This PR make sure the APCU prefix is deterministic only when 2 conditions are met:
composer.lock
file is available--apcu-autoloader-prefix
command line option set.It will be predictable by reusing the
content-hash
key fromcomposer.lock
file.