Composer update: filter packages with security advisories from pool

[glaubinix]

Please note, this is still a very rough draft missing tests, cleanup and taking a few shortcuts. However, feedback is already appreciated.

Idea

Composer already has an audit functionality that reports any package used by a project with security advisories as part of an install/update/audit command. This PR takes this one step further and filters any packages with security advisories from the pool of available packages during a composer updatecommand before the pool get optimized.

The functionality uses cached metadata files wherever possible. However, it is possible that it will trigger a call to the security advisories API endpoint on packagist.org if multiple Composer repositories are defined and not all of them are looked up on packagist.org.

This could potentially replace the need for projects to install a special package defining conflicts with packages that have security advisories.

Sample composer.json

{
    "name": "acme/project",
    "version": "1.0",
    "repositories": [
    ],
    "require": {
        "doctrine/cache": "<=1.3.0,>=1.0.0"
    }
}

How this currently looks in Composer with verbose output

Running 2.7.999-dev+source (@release_date@) with PHP
Reading ./composer.json (/tmp/composer.json)
Loading config file ~/.composer/config.json
Loading config file ~/.composer/auth.json
Loading config file ./composer.json (/tmp/composer.json)
Checked CA file /opt/homebrew/etc/ca-certificates/cert.pem: valid
Reading ~/.composer/composer.json
Loading config file ~/.composer/config.json
Loading config file ~/.composer/auth.json
Loading config file ~/.composer/composer.json (~/.composer/composer.json)
Loading config file ~/.composer/auth.json
Reading ~/.composer/auth.json
Reading ./composer.lock (/tmp/composer.lock)
Reading /tmp/vendor/composer/installed.json
Reading ~/.composer/vendor/composer/installed.json
Loading composer repositories with package information
Reading ~/Library/Caches/composer/repo/https---repo.packagist.org/packages.json from cache
Downloading https://repo.packagist.org/packages.json if modified
[200] https://repo.packagist.org/packages.json
Writing ~/Library/Caches/composer/repo/https---repo.packagist.org/packages.json into cache
Downloading https://repo.packagist.org/p2/doctrine/cache.json
[200] https://repo.packagist.org/p2/doctrine/cache.json
Writing ~/composer-cache/repo/https---repo.packagist.org/provider-doctrine~cache.json into cache
Built pool.
Running security advisory pool filter.
Reading ~/composer-cache/repo/https---repo.packagist.org/provider-doctrine~cache.json from cache
Security advisory pool filter completed in 0.001 seconds
Found 105 package versions referenced in your dependency graph. 1 (1%) were filtered away.
Running pool optimizer.
Updating dependencies
Generating rules
Resolving dependencies through SAT
Looking at all rules.

Dependency resolution completed in 0.000 seconds
Reading ~/composer-cache/repo/https---repo.packagist.org/provider-doctrine~cache.json from cache
Your requirements could not be resolved to an installable set of packages.

Problem 1
  Problem 1
    - Root composer.json requires doctrine/cache <=1.3.0,>=1.0.0, found doctrine/cache[v1.0, v1.1, v1.2.0, v1.3.0] but these were not loaded, because they have security advisories.

Questions

• Should this step be optional
• Should this also consider the audit abandoned config and filter those packages too

[Seldaek]

Cool thanks, not sure either how to answer your questions yet. But I'd say probably needs to be optional, and probably abandoned filtering should also be an option at that level? Maybe like "audit": {"block-insecure": bool, "block-abandoned": bool}?

Does it work on install too btw if an insecure package already made its way into the lock file?

As install runs through the pool builder etc as well, I am thinking it might just work, but it'd be good to test.. And I'm not sure if that should be additionally opt-in behavior as it might break pipelines whenever an advisory is released.

[glaubinix]

Having this as separate config options sounds like a good idea! Applied this already. Blocking on install doesn't work yet as the repository list during the composer install command currently only contains the platform/lock/local repositories and none of the once configured in the repositories section in the composer.json file. So the repository set will always return 0 advisories. Still need to figure out how to pass those through.