- Issue created by @effulgentsia
- Status changed to Needs review
about 1 year ago 6:49pm 6 September 2023 - 🇺🇸United States effulgentsia
Now that the IS is filled out, and since this is a policy issue with no patch needed, setting to Needs review.
- 🇬🇧United Kingdom catch
I agree with the issue summary, the use case seems much more specialised and unnecessary than not having the SSL extension available at all.
- 🇺🇸United States smustgrave
Believe this falls under Plan. The linked issue was also a plan so assume this would be too.
- 🇺🇸United States drumm NY, US
We have gotten very few support requests lately about attempting to connect to Drupal.org with outdated CA bundles. It may have been over a year since the last time I can remember fielding that type of support request. Either everyone's installations have better CA bundles, people know how to update when they see it, we aren't hearing about it when there are problems, or Composer's fallback bundle is helping.
- 🇬🇧United Kingdom catch
One suggestion:
Start off disallowing disable-tls altogether.
Open a follow-up issue to monitor for reports of people having problems with it, then on the basis of that, we could look into allowing it (possibly with a status report warning etc.) if it's a problem.
Seems easier to make it looser later, e.g. in a minor release, than to make it stricter later.
The drawback is if people have problems but don't report them to us, but would think even if that happens we'd get enough reports to notice.
- 🇫🇮Finland lauriii Finland
#8 seems like a good approach from my point of view. Similar to #3364565-25: [policy, no patch] Make PHP's OpenSSL extension a requirement for installing and using Package Manager (and therefore, Automatic Updates and Project Browser) → , what's important from the product perspective is that we have clear messages when then requirements are not met, and documentation for how users may try to get make their environment compatible.
- Status changed to RTBC
about 1 year ago 12:09pm 3 November 2023 - 🇬🇧United Kingdom catch
For all the same reasons as 🌱 [policy, no patch] Make PHP's OpenSSL extension a requirement for installing and using Package Manager (and therefore, Automatic Updates and Project Browser) Fixed I'm going to remove the release manager review here and mark this RTBC. It would be good if a framework manager who's not me could also remove that tag or otherwise comment.
Per 🌱 [PP-*] [policy] Allow package manager to work without openssl and/or a valid certificate bundle Active if we TUF-proxy packagist and github on Drupal.org, or if packagist enables TUF itself, we might be in a better position to reverse this decision later on. However for now it gives us a starting point where we can make things less restrictive rather than more restrictive later, if the assumptions in the issue summary that this particular setting should be easy to resolve for any sites that hit it is true.
- 🇺🇸United States effulgentsia
I opened this issue, so I'm biased, but since other committers have also +1'd it, I think it's okay for me to also provide the framework manager signoff, so removing that tag.
Leaving at RTBC for at least a few days to give people a chance to object before marking it fixed.
- Status changed to Fixed
12 months ago 4:07pm 24 November 2023 - 🇬🇧United Kingdom catch
Going ahead and marking this fixed per the above, as well as the general agreement on 🌱 [policy, no patch] Make PHP's OpenSSL extension a requirement for installing and using Package Manager (and therefore, Automatic Updates and Project Browser) Fixed , since it's been RTBC for over three weeks now and all sign-offs have been done. We have 🌱 [PP-*] [policy] Allow package manager to work without openssl and/or a valid certificate bundle Active to discuss this further if it turns out to cause problems for people after all.
Automatically closed - issue fixed for 2 weeks with no activity.