[PP-*] [policy] Allow package manager to work without openssl and/or a valid certificate bundle

Drupal.org proxying all of packagist/github and TUF signing releases on their behalf.

I just want to point out that this would not just be all drupal core or even the entire contrib ecosystem's package dependencies. It would likely be all of packagist because we don't know what dependency any custom module would have. This would mean we would need to monitoring of all packagist packages. We looked at just-in-time mirroring but I think that would be very complicated.

This would also likely mean we would need another security review for this mirror system.

Note that I've opened this as a core issue but all of the actual major work is on the DA infrastructure side (or packagist itself).

We ask a lot of the DA, With Automatic Updates and Project Browser we have strategic initiatives that are unable to proceed without significant work from the DA already. I hope before we ask the DA run a complete mirror of Packagist we weigh that against the other work DA could be doing that would also benefit the Drupal community and even benefit Automatic Updates and Project Browser initiatives. Also asking them to build this mirror also means we would have to ask to maintain it for the foreseeable future, therefore it would mean they would less capacity for years.

For instance 📌 [policy, no patch] Use Update XML in Package manager to determine release support status Active may mean we rely on the Update XML for "supported" status of projects. The Update XML are protected by https but not TUF protected. It seems it would be more impactful use of DA time and money to work to expose the information in Composer metadata which will then mean that it is TUF protected.

This will would benefit all sites that are using the system.

Explicitly postponing this on 🌱 Collect data on openssl and tls support across hosting environments Active , apart from it being complicated and expensive to implement, we also need to know if anyone would actually be stuck without it.

Superb write-up of trade-offs in #3, @tedbow, thanks!

Similarly, thanks for the cyrstal-clear write-up in the issue summary, @catch.

I want to provide some additional detail for point 1 in the issue summary, where @catch wrote:

1. Drupal.org proxying all of packagist/github and TUF signing releases on their behalf. This has been discussed as an option if packagist is unable to implement TUF itself for a long time. This would still rely on https between Drupal.org and packagist/github, but then would provide more control over other aspects - not just a technical proxy but a trust proxy.

• Sentence 1 () would be a HUGE $$$ cost, potentially forever? 🤯
• Everything else: we know for a fact that Packagist will be unable to implement TUF for a long time to come, if ever, thanks to @naderman from the Composer project having explained in detail at DrupalCon Lille. The reason being that Packagist essentially only stores/controls metadata, not the actual files/downloads. Those are typically served from GitHub. And GitHub's architecture means file signatures (hashes) are not the same: they change for the exact same release (vendor/foo:3.2.0) per geographical location as well as over time!

+1 to both #3 and #5.