How to force composer audit to rely non-dynamic TUF-protectable resources

[tedbow]

The Packagist API allows providing a URl to dynamically fetching security advisories. https://packagist.org/apidoc#list-security-advisories. I believe this is used by Composer Audit

From a TUF perspective this is not good because the dynamic nature of the possible query arguments probably makes it impossible to protect as a TUF resource.

We should determine if it possible to make composer audit rely on resources that can be TUF protected

1. When does Composer call dynamic security advisories query?
2. Is possible to tell Composer not to use these requests on certain repos?
3. If 2) is not possible, is it possible to intercept and forid these call on TUF protect resources?
4. If we do 3) will audit and any other Composer operation fallback to using the security advisories in the .json files for packages? Is this the same information in just different form?

related drupal.org issue https://www.drupal.org/project/project_composer/issues/3301876

[phenaproxima]

is it possible to intercept and forid these call on TUF protect resources?

If it's possible, I heartily and vigorously suggest we do NOT do this. Essentially disabling the ability to audit would thoroughly undermine our mission and shatter any credibility we have.

I think it is more valuable, from an end-user security perspective, to allow auditing without TUF, than it is to forbid auditing because it cannot be protected by TUF.

[phenaproxima]

And since you ask, Composer uses \Composer\Repository\AdvisoryProviderInterface to determine if a repository can provide security audits.

So in a TUF-protected repository, theoretically we could always force security advisories to be loaded from signed data, rather than from an API.

[tedbow]

@phenaproxima that is why I put 4

If we do 3) will audit and any other Composer operation fallback to using the security advisories in the .json files for packages? Is this the same information in just different form?

I believe that Composer audit is not dependent on these dynamic calls rather it can use the information in each package about security advisories.see https://packages.drupal.org/files/packages/8/p2/drupal/webform.json and the security-advisories section.

But looking at \Composer\Repository\ComposerRepository::getSecurityAdvisories() it appears that it is possible to use tge info in the individual package instead but I am not sure in what circumstances.

[tedbow]

Related to the drupal.org I mentioned above and related to any repository implementation that wants to implement TUF, does it actually make sense for those repos not to provide the api-url for security advisories because

1. Composer seems to able to use the security-advisories in individual packages during composer audit instead of this dynamic call
2. The dynamic resource can't be TUF so it defeats the purpose of implementing TUF if arguably those most security sensitive info is then not TUF protected.
3. While the dynamic call is probably more convenient than looking through all the individual package .json files, I am not sure who the other potential callers would rather than Composer itself(which has other sources for this info).

[tedbow]

Brought this issue up on a composer issue composer/composer#10329