Misleading section on urllib3 and OpenSSL 1.1.1

[sethmlarson]

Hello! I saw the most recent post about RTD configuration files, there is a section about urllib3 and OpenSSL:

We plan to deploy these changes and start failing builds without a configuration file in September > 2023. This matches the period when urllib3 drops support for OpenSSL 1.1.1 which is the OpenSSL version installed by the build image used when the project doesn’t specify a configuration file.

This mentions urllib3 dropping OpenSSL 1.1.1 in September 2023 and links to the issue, but in the issue it only mentions that the LTS release of OpenSSL 1.1.1 will no longer be supported by the OpenSSL team. urllib3 will continue working for a long time with OpenSSL 1.1.1.

I wonder if this was confused with urllib3 not supporting OpenSSL versions earlier than 1.1.1 in urllib3 v2.0 and Readthedocs was using a default build image that used OpenSSL 1.0.2 which was causing issues.

Let me know if I can help figure out any other confusing parts, there's a lot of numbers and different moving pieces. Thanks again for helping out urllib3 users!

cc @humitos @benjaoming @agjohnson

[benjaoming]

I think this is the same input: https://twitter.com/graingert/status/1664054263461314560

So the correct text would be?

This matches the period when urllib3 drops support for OpenSSL <1.1.1

Edit: No that doesn't make sense.

[benjaoming]

Or maybe the better update would be:

This matches the period when OpenSSL 1.1.1 becomes unsupported. A recent release of urllib3 dropped OpenSSL <1.1.1 support and once support of OpenSSL 1.1.1 is dropped (September 11, 2023), we expect urllib3 to eventually drop the support, too, and our legacy build images will start failing again. This would effect all projects that don’t specify a configuration file, hence the timing of this change.

[benjaoming]

I don't like how long and speculative this sounds - maybe we can move it "below the folds" into a background/motivation section.

[agjohnson]

@sethmlarson Thanks for the clarification! If I understand, it sounds like you aren't intending to do another release like urllib3 2.0 when you drop support for libssl 1.1.1?

I wonder if this was confused with urllib3 not supporting OpenSSL versions earlier than 1.1.1 in urllib3 v2.0 and Readthedocs was using a default build image that used OpenSSL 1.0.2 which was causing issues.

To maybe break some of our assumptions here, when urllib3 2.0 was released and added the deprecation exception for libssl < 1.1.1, we did notice immediate errors because libssl 1.0.2 was used to compile Python in our old build images.

So, we assumed that urllib3 dropping support for libssl 1.1.1 would be similar -- urllib3 would cut another release with a deprecation error added and we would notice build failures.

Is it the case that a deprecation error is not going to be added to the new release in Sept? That would be fantastic news for us actually.

[sethmlarson]

@agjohnson Indeed we aren't planning on dropping support for OpenSSL 1.1.1, there will be no new deprecation warnings in the near future. Glad to know that's good news for yall, we appreciate very much upgrading the base image to use OpenSSL 1.1.1 :rocket:

[agjohnson]

@sethmlarson That's great news, I'm glad you jumped into this issue to help clarify

I don't think we even need to mention urllib3 or libssl now, though we can note the edit to this post at least. The libssl deprecation was dictating the timeframe we wanted to aim for with our own deprecation, but the primary motivation for us is just upgrading projects using outdated configurations.

Thanks again @sethmlarson we appreciate the heads up!