Problem/Motivation
Previously discussed in #3364565: [policy, no patch] Make PHP's OpenSSL extension a requirement for installing and using Package Manager (and therefore, Automatic Updates and Project Browser), #3398988: Collect data on openssl and tls support across hosting environments, and #3385409: [policy, no patch] Disallow using Package Manager (and therefore Automatic Updates and Project Browser) when Composer's disable-tls setting is true.
The very original design of package manager and TUF was in part to enable a secure experience without requiring https. We realised in the past year or so that many parts of the PHP ecosystem already require https. Additionally, packagist has confirmed that while they're interested in TUF, there are barriers to adopting it, such as the inability to sign zips from github (which can be different files every hour or so, generated dynamically depending on github location). This means that we essentially have no choice but to require the openssl extension and tls at the moment.
If we discover that openssl is a significant barrier to automatic updates adoption, we could reverse this decision and look at providing a TLS-enabled, http endpoint for package manager to fall back to.
Steps to reproduce
Proposed resolution
It's my understanding that this would require at least two things:
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.
2. For this issue, Drupal.org would then additionally need to provide an http version of that endpoint. This endpoint would then rely 100% on TUF between Drupal.org and the site, and on https between Drupal.org and packagist/github, which (pending unknown vulnerabilities) we believe should still be secure.
Note that when openssl is enabled but the server has a bad certificate bundle, step #1 here would enable sites to be TUF-protected without a working SSL implementation. However because composer ships with a fallback certificate bundle from mozilla, this situation is much more likely to have a local workaround for the Drupal install.
tl;dr, #1 enables us to remove the disable-tls requirement and #2 enables us to remove the openssl extension requirement, assuming no other blockers. If packagist independently implements TUF, that might make #1 redundant too, although there could be other packagists, manually added github repos etc.
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).
