Add COMPOSER_NO_AUDIT constant ?

[jrfnl]

Describe the feature

Composer 2.4.0 introduced a new "Audit" feature, which will run automatically on any composer update, require, remove and create-project.

This audit feature may break builds when security vulnerabilities are found.

As of Composer 2.4.1, a new COMPOSER_NO_AUDIT env variable is available to automatically apply the --no-audit option to all commands which are subject to audits.

I wonder if - similar to the previous addition of COMPOSER_NO_INTERACTION - this new COMPOSER_NO_AUDIT env variable should be turned on by default from within the setup-php action runner.

What do you think ?

Refs:

• https://blog.packagist.com/composer-2-4/
• https://github.com/composer/composer/releases/tag/2.4.1
• Environment variable for --no-audit. composer/composer#10998

Version

• I have checked releases, and the feature is missing in the latest patch version of v2.

Underlying issue

Builds in CI may start failing unexpectedly and unrelated to any changes made in a PR/branch due to the audit throwing something up.

Describe alternatives

Alternatively, people would need to add the --no-audit flag to their Composer commands themselves.

Are you willing to submit a PR?
Happy to try.

[Seldaek]

I am not sure what the best default is here tbh. Just to be clear though:

During updates the audit is will simply output some warning but not fail the build if there is a known vulnerability found.

If you simply run install no audit is done by default.

If you want to fail the build in case vulns are found, then you kinda need to explicitly call the audit command, in which case disabling the auto-audit on update may make sense.

[jrfnl]

@Seldaek Thanks for pitching in - I'd been trying to get the audit command to throw up a response, but couldn't find a repo where it did (I suppose that says something about the projects I work on), so I hadn't been able to verify the exit code. Good to know that the exit code will - in non-explicit audit circumstances - still be 0.

Still, in CI scripts for packages which need to be cross-version compatible, a (selective) update is often run, if for no other reason than to get the correct PHPUnit version for the PHP version being tested, so I guess adding the ENV variable would reduce noise in the logs in that case.

[Seldaek]

If you wanna test things you can require symfony/security-core for ex in a version that is affected by an advisory per https://packagist.org/packages/symfony/security-core/advisories

[shivammathur]

@jrfnl @Seldaek

Although, it does not break the workflows. I will merge a PR for this now and let's see if we get feedback otherwise.

I would not rely on audit check in the update/require steps as they do not fail on vulnerabilities in the current implementation, and in CI most people ignore the output of successful steps.

So projects that want this functionality in CI should add a composer audit step which fails before the install/update/require commands.

[jrfnl]

Thanks @shivammathur ! Let's wait & see for any feedback.

[shivammathur]

Released in 2.22.0.