[imanimanyara]

Summary

The reusable security.yml accepts php-version and php-extensions, honours both in composer-audit, and ignored both in osv-scan, which hardcoded php-version: '8.4' and set no extensions.

Any caller whose composer.json floors PHP above 8.4 therefore fails the OSV job — and fails in a way that points nowhere near the cause.

How it presented

laranail/chrono ("php": "^8.5") failed its first run of this workflow with:

##[error]Your requirements could not be resolved to an installable set of packages.
##[error]Process completed with exit code 2.

That is composer, in a job named "OSV.dev scan", in a step named "Set up PHP" — and the message names neither PHP nor a version. The obvious reading is that OSV-Scanner is broken. It isn't; composer was refusing to resolve a ^8.5 requirement against an 8.4 runtime.

Why it stayed hidden

The other four pilot repositories declare "php": "^8.4.1 || ^8.5", so 8.4 satisfies them and the job passed. A default that happens to suit most callers hides the bug behind the ones it suits, and surfaces it only on the caller with the highest floor — which is also the caller least likely to be the first one tried.

The fix

Both values now come from the inputs, in both jobs. The literal is replaced, not supplemented, so there is no second place for the two to drift apart.

Verified

• php-version: ${{ inputs.php-version }} at 2 sites, extensions: ${{ inputs.php-extensions }} at 2 sites, hardcoded '8.4' at 0 — counted with grep -F, because { is a metacharacter under ugrep and the first count came back 0 against a correct file.
• YAML parses; all three jobs intact.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.