Problem/Motivation
PHP's OpenSSL extension is required for Composer to fetch package metadata and distribution tar/zip files via https URLs rather than http URLs. Note that fetching data via https doesn't by itself guarantee security (the OpenSSL library on the machine can be outdated, certificates might not be verified correctly (or at all), the package repository itself can get compromised, etc.), which is why Package Manager is also incorporating package signing, at least for packages on drupal.org and drupal/* packages on GitHub. The scope of this issue isn't about those other security concerns, only about whether or not to allow sites to install/use Package Manager on PHP installations that do not include the OpenSSL extension.
Arguments in favor of requiring PHP's OpenSSL extension:
- As far as I can tell, api.github.com does not support http requests. For example, the response to
curl -v http://api.github.com/repos/symfony/http-foundation/zipball/718a97ed430d34e5c568ea2c44eab708c6efbefb(the zip containing the 6.3.0 release of symfony/http-foundation) is a 301 redirect to the https URL. Therefore, on sites without the openssl extension, Package Manager would be unable to download any packages from GitHub, which is where Symfony and other Drupal dependencies are hosted. In order for Package Manager to work on site without the openssl extension, we could in theory run a proxy on drupal.org to serve GitHub's files over http, but it's questionable whether operating such a proxy is a good idea. - Although we're adding TUF package signing for packages on drupal.org and for packages within the
drupal/namespace on GitHub, neither Packagist nor GitHub implement TUF package signing for Drupal's dependencies. If we create a proxy to allow those packages to be downloaded without https, then we'll need to add TUF signing to them since otherwise those sites could be easily compromised by an adversary-in-the-middle attack. This would present both technical challenges (do we sign all dependencies of every contrib project and if so, what performance/scalability issues arise from that?) as well as messaging challenges (what does it mean for Drupal to be blindly signing non-Drupal packages?).
Arguments in favor of not requiring PHP's OpenSSL extension:
- We don't know what percentage of Drupal sites are on servers that don't have the OpenSSL extension and where the site owner is not in control of that. If it's more than a tiny amount, then it would be unfortunate to exclude those sites from Automatic Updates. We suspect that in the past this was a significant amount of sites but that through the work of Let's Encrypt and others that it is now a much smaller amount, but we don't have data to confirm or quantify this hypothesis.
Proposed resolution
Assume that in 2023, until proven otherwise, that PHP configured without the OpenSSL extension is an outlier. And therefore, initially release Package Manager and Automatic Updates in Drupal core with a requirement on the OpenSSL extension. If we later learn that there remains a large enough segment of Drupal sites on PHP hosting without OpenSSL, then we can revisit creating a GitHub proxy and signer.
Remaining tasks
Product manager signoff.