Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.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).
Remaining tasks
Postponed on #3398988: Collect data on openssl and tls support across hosting environments
Comments
Comment #2
effulgentsia commentedComment #3
tedbowI 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.
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 #3394754: [policy, no patch] Use Update XML in Package manager to determine release support status 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.
Comment #4
catchExplicitly postponing this on #3398988: Collect data on openssl and tls support across hosting environments, apart from it being complicated and expensive to implement, we also need to know if anyone would actually be stuck without it.
Comment #5
wim leersSuperb 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:
vendor/foo:3.2.0) per geographical location as well as over time!Comment #6
catch+1 to both #3 and #5.
Comment #7
quietone commentedAdding postponed item to the list of remaining tasks per the issue summary field documentation, remaining task.