[policy, no patch] Decide if and when automatic updates should rely only on packagist data to determine installability of modules

https://github.com/composer/composer/issues/8272 would put a key piece of information in Packagist data. In general, it would be useful for Composer/Packagist if we test something out in the plugin space before they implement it in an official way. I’d want the initial data structure to be at least vetted as something that could be on track to be in Composer later. Then we include the extra data ahead of that, and write the plugin in a way that it’s okay to remove the extra data at any time, we don’t want it in the test structure and final structure for too long.

Does someone from the core side want to raise their hand to help define what would need to be in the composer.json data structure in order to make this happen?

Or perhaps even to propose the larger example of what else might be needed to fully replace info.yml files?

Or perhaps even to propose the larger example of what else might be needed to fully replace info.yml files?

I don't think we should touch that with a 10ft barge pole in this issue. Various discussion in ✨ Replace .info.yml with composer.json for extensions Postponed and #3250765: [meta] Clean up .info.yml files → .

Another wrinkle in this is when a created 📌 [policy, no patch] Use Update XML in Package manager to determine release support status Active assumed that the Composer metadata for drupal projects that Composer relies would be TUF protected because drupal.org is setting up this protection. This is true for the packages.json and the files like https://packages.drupal.org/files/packages/8/p2/drupal/webform.json(when TUF protection is in production)

but looking at ✨ Implement “list security advisories” Packagist/Composer API Fixed This is wil be more information that drupal.org provides composer but I don't see how this could be TUF protected. For instance composer audit would make a request like https://packages.drupal.org/8/security-advisories?packages[]=drupal/tfa&packages[]=drupal/swiftmailer. Since packages in the URL query would be dynamic each site would send a different list based on the projects installed and get different results.

Right now when I run composer audit -vvv I see

Downloading https://packagist.org/api/security-advisories/
[200] https://packagist.org/api/security-advisories/
Found 2 security vulnerability advisories affecting 2 packages:

but no request for to <code>https://packages.drupal.org/8/security-advisories?... but I presume that would happen when ✨ Implement “list security advisories” Packagist/Composer API Fixed is implemented completely. At that point I think this info can be TUF protected.

Yes, https://packages.drupal.org/8/security-advisories?… can not be TUF protected, since it is dynamic. The Composer plugin will either have to remove the fetch from there, falling back to the current behavior using each individual project's metadata; or make sure the security-advisories data is fetched safely and matches the individual project metadata.

@drumm Ok thanks for the info
I have made a github issue for the Composer plugin https://github.com/php-tuf/composer-integration/issues/99

@drumm I asked in that issue but raising it here also. It seems that Composer has other ways to get the security advisories during `composer audit`. Given that what are the advantages of implementing this API. Are there other callers besides Composer itself?

I was going off of the reasons in ✨ Provide security-advisories API endpoint Fixed for implementing this.

Okay I asked for guidance in the Composer issue queue https://github.com/composer/composer/issues/10329#issuecomment-1936032187