I've read through this bug and I don't see a good way forward with a solution here. OpenSSL 1.1.1 doesn't provide the exact API that is required to solve it, which would probably be 3) as suggested above, but I don't think Ubuntu should change the meaning of the value returned by that API.
Ubuntu is returning the value that is expected of the upstream 1.1.1 code when security levels are used. While Ubuntu, Debian, and Fedora use different approaches to achieve a similar goal, and Ubuntu did modify the meaning of security level 2 to restrict it further than the upstream default, the fact remains that building OpenSSL with a higher default security level results in a situation where there seems to be no good API to request what the minimum TLS version is. It may appear reasonable that a simple query to the current security level could have given a hardcoded indication of what is available. Unfortunately, that assumption doesn't stand the test of time as it is no longer valid once the security levels have been modified to align with the current best practices, either in a new OpenSSL release, or by a distro. This is a less than ideal situation, but I think the only way forward currently available when obsolete TLS versions need to be used is to set the minimum security level accepted by OpenSSL. We should work with upstream OpenSSL to make sure 3.0 provides the right APIs, documentation, and guidance that are required to handle changing defaults like this more elegantly in the future. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1899878 Title: Python's test_ssl fails starting from Ubuntu 20.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1899878/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
