All commit authors signed the Contributor License Agreement.

Every change to Python requires a NEWS entry.

Please, add it using the blurb_it Web app or the blurb command-line tool.

Every change to Python requires a NEWS entry.

Please, add it using the blurb_it Web app or the blurb command-line tool.

According to the OpenSSL wiki, the configure flags are:

• no-ssl2: Disables SSLv2. OPENSSL_NO_SSL2 will be defined in the OpenSSL headers.
• no-ssl3: Disables SSLv3. OPENSSL_NO_SSL3 will be defined in the OpenSSL headers.

$ grep -r OPENSSL_NO_SSL Modules/_ssl.c
Modules/_ssl.c:#ifndef OPENSSL_NO_SSL3_METHOD
Modules/_ssl.c:#define OPENSSL_NO_SSL2
Modules/_ssl.c:#if defined(SSL3_VERSION) && !defined(OPENSSL_NO_SSL3)
Modules/_ssl.c:#elif defined(SSL3_VERSION) && !defined(OPENSSL_NO_SSL3)
Modules/_ssl.c:#if defined(SSL3_VERSION) && !defined(OPENSSL_NO_SSL3)
Modules/_ssl.c:#ifndef OPENSSL_NO_SSL2
Modules/_ssl.c:#ifndef OPENSSL_NO_SSL3
Modules/_ssl.c:#if defined(SSL2_VERSION) && !defined(OPENSSL_NO_SSL2)
Modules/_ssl.c:#if defined(SSL3_VERSION) && !defined(OPENSSL_NO_SSL3)

@erlend-aasland You're completely right it's not referring to context flags but configure options (and it's the SSLv3 that's wrong, not the SSLv2)! I'll reword the original meaning to make it less ambiguous. Really appreciate the review ❤️

Thanks @janbrasna for the PR, and @erlend-aasland for merging it 🌮🎉.. I'm working now to backport this PR to: 3.10, 3.11.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

GH-92949 is a backport of this pull request to the 3.11 branch.

GH-92950 is a backport of this pull request to the 3.10 branch.

Thanks, @janbrasna!

The changeset doesn't make much sense. SSLv2 and SSLv3 are no longer supported anyway. Even TLS 1.0 and 1.1 should be considered unsupported these days.

The changeset doesn't make much sense.

It fixes:

• a trivial spelling mistake; makes sense IMO
• an incorrect reference to how one can build openssl; makes sense IMO

I do agree that we should consider rewording all of those deprecated/obsolete features anyway, but that is out of scope for this PR.

Can you explain what is incorrect? I'll put up a PR to fix it :)

@tiran That's where I actually came from originally, trying to understand the current support (defaults, options) with only information about the actual PROTOCOL_SSLv* constants deprecated being documented, the rest is left to the OpenSSL configuration (therefore without any inherent domain knowledge what is the right way to understand that "SSLv2 and SSLv3 are no longer supported anyway"?). Inferring from PEP-0644 and my anecdotal insight into OpenSSL 1.1.1 it's only SSLv2 that's completely removed but the same doesn't necessarily be true for SSLv3(?) — hence my intent to fix up the docs to make sure those who really want to be certain they've ruled out any legacy protocols have the current information.

What I see from https://www.openssl.org/docs/man1.1.1/man3/SSLv3_method.html is that 1.1.0 dropped support for SSLv2, nonetheless features mentioning SSLv3 are still sparsely present between 1.1.0–1.1.1 as well as the options to compile with enable-ssl3 still functioning(?) compared to the no-ops for enable-ssl2 that just do nothing. (Putting aside that enable-ssl3* itself might be working yet no-ssl3* might be forced at the same time etc., my openssl-fu doesn't go that far…)

@erlend-aasland I believe that from today's point–of–view the more current info might be:

1. the openssl config wording should be reversed, as the protocols are today (or were when last working) optional to enable, not optional to disable(?)
   (judging from defaults /anecdotal evidence/ yet can't tell the change from opt-out to opt-in can be relied on universally)
2. since 3.10 and PEP-0644 the SSLv2 can't be enabled at all(?)
   (just don't know the exact situation preceding the pep not to paint an incomplete picture of the options in past)

However that all changes the semantics of the docs and that's not something I was really comfortable with, esp. with deprecation and compatibility information, that someone more knowledgable from the core devs might provide with better precision, to actually update the deprecated protocol support info with current status. (For posterity, as long as the deprecated constants are being kept around; explaining not only they're deprecated, but they actually might not function at all for upstream reasons;)

I suggest you open an issue, and we can continue the discussion there.