Would you like to take over maintaining this module? I appreciate all this work, but I'm not in a great position to review patches and do releases for this project these days.
It looks like no one from Pantheon has commented on this issue.
/waves
I agree with @effulgentsia's perspective on looking at feature requirements more than super long support/distro lifecycles. Some sites just need to launch to support an event, and MariaDB 10.6 will remain a perfectly reasonable choice for projects like that; the EOL is still years out. If someone decides to run Drupal on an EOL DB version, then it's at least slightly unsupported as a stack in general -- and not by our doing, anyway.
Generally, reducing friction is good.
As for the Pantheon question, I don't know any ETA for next MariaDB version offerings. I can share that we're considering picking up GCP Cloud SQL as an option for running sites, which would offer actual MySQL, potentially more than one choice amongst the 5.7+ choices (which include an 8.0 offering). We would definitely offer MySQL 8.0 if we offer any Cloud SQL options.
This thread is already quite comprehensive, so I'll try to be brief.
I support strong product managers. Any burden of proof should be on retaining a process that causes friction, and I'm especially loathe to situate processes in Dries' hands in ways he doesn't see as ideal.
My other rule of thumb goes like this: "If someone ultimately oversteps a permission boundary, is it auditable and easily reversible on review? If so, consider whether it should be a boundary at all." By that measure, it's not like these approvals are the final step for a major change ending up in a release, I assume. So, the consequences for finding the process overly frictionless seem low.
In case we end up in a place of conflict, that seems exactly when Dries would step in as a "tiebreaker" anyway, which also suggests low risk for this change versus the status quo.
FWIW, we do rely on openssl_* functions directly for CA bundle verification (in composer/ca-bundle), as well as in self-update to verify the phar file signature.
So, leaning on my earlier suggestion to "require what will make Composer work," we would add/revise two requirements: (1) OpenSSL for PHP and (2) curl for PHP with functional TLS. I think we already require curl, so the latter might just be a small revision. Almost all curl is built with TLS, so "OpenSSL for PHP" is the real change here.
Composer already includes one from Mozilla that they keep up to date
Oh, interesting. Does it also fall back to the bundled CAs if the system CA trust roots are out of date (read: are missing essential roots of trust for key servers/endpoints)?
BTW, it's not just about HTTPS versus no HTTPS. It's about weird, buggy, or problematic old versions of OpenSSL or TLS or whatever on older hosting stacks. At least, that's the risk AutoUpdates has been trying to mitigate since 2018. I'm going to ask David Strauss to comment on this issue since he was historically very concerned about this.
xjm is correct about my concerns: we don't know the status of TLS client stacks on host systems. It's also hard to reason about them based on data we do have, too:
- The TLS server stack for accessing a site may not be the same as the TLS client stack PHP may use for outbound requests. Even if a server uses the same TLS stack for server and client purposes, it being old/broken can be masked by something like throwing Cloudflare in front of the server. This issue affects ciphers and protocol versions.
- A TLS stack that works fine for server purposes may fail for client purposes if the CA roots of trust on the client are missing or out of date. Let's Encrypt cross-signed for a while, but I believe they're now reliant on CA chains having their native root. This may also affect CAs like Fastly's emerging Certainly. We could ship and use our own CA data if we wanted to, but that has its own brittleness.
- Even if we know the TLS client stack works properly for a specific connection Drupal makes, that only tells us that the stack is modern enough for that particular negotiation. Drupal.org requires TLS 1.2 and doesn't provide 1.3 at all, and it's not clear when >=1.3 will become a thing like >=1.2 did a few years ago.
- TLS is sometimes messed with by nation states and corporate firewalls in ways that work fine for one purpose and break for another.
That all said, we've addressed my main concern with even our limited investment into TUF. If we find ourselves bitten by these issues, we have methods to isolate our root of trust and evaluation of the integrity of the chain.
My only question about requiring OpenSSL is whether it's the right requirement to ensure a (likely) functional client TLS stack. libcurl can leverage to other libraries like NSS; we have even used this in the past at Pantheon when Red Hat was trying to consolidate on NSS. Unless Composer leans on OpenSSL directly, libcurl will leverage whatever TLS it's built with.
Oh, and here's another wrinkle: Whether PHP is built with OpenSSL bindings is different from what libcurl is built with and using. It's possible to have libcurl be able to access HTTPS resources securely without OpenSSL directly linked into PHP at all. It's also possible for libcurl to be built with something like NSS and still have PHP linked to OpenSSL.
So, I would propose that the correct requirement here involves understanding how Composer uses HTTPS/TLS and requiring that. There's a good chance that the requirement we should have is that PHP's libcurl is built with TLS support -- and that should be actually more universal than whether PHP itself is linked with OpenSSL. Also, PHP can use its own bundled libcurl (IIRC, the default) or system libcurl (not the default but commonly used by distro packagers like in the Red Hat world), so any check of curl capabilities should use the PHP API and not shell out.
I see. This is about the large Surrogate-Key header. We should avoid setting that when we're not on the Pantheon platform -- unless perhaps re-enabled in settings.php.
We should probably just make the module more resilient/self-disabling when it's not actively running on Pantheon. Do you know where it's hanging?
hestenet → credited David Strauss → .
hestenet → credited David Strauss → .
hestenet → credited David Strauss → .
hestenet → credited David Strauss → .
hestenet → credited David Strauss → .
hestenet → credited David Strauss → .