Only audit packages we actually provide

[phenaproxima]

I discovered why Composer makes so many extra requests for packages that are not part of a particular repository (as surfaced in composer/composer#11704 and php-tuf/drupal-project#1) -- composer require and composer update will do a security audit by default, unless you pass the --no-audit option. While auditing, repositories that support it are queried for all packages, even ones they don't provide.

To be clear, this is an upstream bug in Composer and still needs to be fixed; I will update and repurpose composer/composer#11704. But we can work around it by overriding ComposerRepository::getSecurityAdvisories() so that, if we are using an available-package-patterns filter, we don't try to get security advisories for packages we don't provide.

[tedbow]

We need some sort of test for this because the worst case scenario is that we accidently unset it for package we are suppose return an advisory for and the whole system doesn't work.

One idea is to 2 repositories set up both "security-advisories" set up and have both packages installed with insecure versions. Then do a composer audit then confirm only the one we expect to filtered out is actually filtered out

[phenaproxima]

Looks like the upstream bug was fixed in Composer: composer/composer#11704.

Do we want to just close this out?

[phenaproxima]

Here's how we could test this out manually. In a Drupal project (just a regular recommended-project will do), running composer update -vvv should NOT have requests like this in it:

Downloading https://packages.drupal.org/files/packages/8/p2/consolidation/annotated-command.json

That's an example of Composer asking a repository for info on a package it does not have, and never has.

[phenaproxima]

Can confirm that, testing manually with Composer 2.7.7, I didn't see any of those bad requests.