Problem/Motivation
This is a follow-up discussion to #3394754: [policy, no patch] Use Update XML in Package manager to determine release support status, the relevant (postponed) implementation issue is #3359820: Use the packagist endpoint instead of update XML to determine which updates are supported/installable.
In #3394754: [policy, no patch] Use Update XML in Package manager to determine release support status, we decided that automatic updates should use project XML data from Drupal.org (which is served over https, but is not TUF-protected) for checking whether a release that can be updated to is supported. Because 'supported' is a Drupal.org concept that doesn't exist in the packagist world, it's not in the packagist data at all.
The idea is that AU will check the supported status to reduce the likelihood of updating someone to a 'bad' release - either a paper bag that has been hastily marked unsupported until a hotfix can be released, or a dead-end minor branch of a contrib module.
However, it leaves open certain possibilities of freeze attacks (i.e. an attacker marking perfectly good releases of modules as unsupported to stop people updating to them).
In this issue we need to decide two things:
1. Do we want to move (duplicate) this additional data that's currently only in the update XML to d.o's packagist endpoint - if so we'll need an implementation issue against project_composer to do so. In the previous release we decided this shouldn't be alpha blocking, because once we add this to the data, it will be very hard to change the format, so it might take time to figure out how we want to do that.
2. If the answer to #1 is yes, is this beta or stable blocking for automatic updates, or just a 'nice to have'?