I'm testing 3.5.10rc1 on a freshly installed Linux (Pop!_OS 20.04), and I'm getting a lot of these test failures:

ssl.SSLError: [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:2951)

Apparently the 2048 keys used in the tests are considered "too small" with brand-new builds of the SSL library.

Christian: you upgraded the test suite keys to 3072 bits back in 2018 (issue #34542), but didn't backport this as far as 3.5 because it was in security-fixes-only mode.  I experimented with taking your patch to 3.6 and applying it to 3.5, but 80% of the patches didn't apply cleanly.  Could you either backport this upgrade to 3.5 (I'll happily accept the PR), or advise me on how to otherwise mitigate the problem?  I don't really want to turn off all those tests.  Thanks!

I'll look into it.

New changeset d565be84993a3d618add139cf21038e12c60a13e by Christian Heimes in branch '3.5':
bpo-41183: Update test certs and keys (#21258)
https://github.com/python/cpython/commit/d565be84993a3d618add139cf21038e12c60a13e

Thanks for the backport!

Christian:  Help!  Again!

I merged your PR, pulled a fresh copy, built it, and ran the test suite.  I get seven failures in I think the same modules.

Most of the failures are either "ssl.SSLError: [SSL] internal error (_ssl.c:728)", or some flavor of "OSError: [Errno 0] Error".  Sadly not helpful.

But!  Occasionally the test suite prints a very telling error:

ssl.SSLError: [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:3233)

Attached is the output of running just those seven tests.  (One test is now working, not sure why.)

Obviously these tests pass on the buildbots, I assume that's because their OpenSSL is slightly older.  But I don't think I can ship 3.5.10rc1 if it won't build with current OpenSSL.

You should be able to simply pull the current 3.5 head (d565be84993a3d618add139cf21038e12c60a13e) to reproduce the error.

Upgrading to release blocker.

I'm testing with latest build of OpenSSL 1.1.1 and Fedora's DEFAULT crypto policy here. Your vendor may have configured OpenSSL with a more strict crypto policy. 

Could you please attach a full output of ./python -m test -v test_ssl?

Does the 3.6 test suite pass on your test machine?

test_ssl was one of the seven modules that failed.  But attached here is just the output of

% ./python -m test -v test_ssl >& test_ssl_failure

The 3.6 branch of python/cpython fails as well on this machine.  Output attached.

I assume this is building against the system OpenSSL.  On this machine, the "openssl", "libssl1.1", and "libssl-dev" packages are all version "1.1.1f-1ubuntu2".

The OS is "Pop!_OS" version 20.04, which is a derivative of Ubuntu 20.04.  It appears to be getting this package straight out of the Ubuntu package repo.  The maintainer is listed as "Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>".

Attached is the revision history, copied and pasted out of the package manager's "changelog".

test_ssl_36_branch just contains "1 test failed: test_ssl". Could you please attach a verbose run?

The problems are caused by security policy. We had similar issues in Fedora.

    - Set OPENSSL_TLS_SECURITY_LEVEL=2 as compiled-in minimum security
      level. Change meaning of SECURITY_LEVEL=2 to prohibit TLS versions
      below 1.2 and update documentation. Previous default of 1, can be set
      by calling SSL_CTX_set_security_level(), SSL_set_security_level() or
      using ':@SECLEVEL=1' CipherString value in openssl.cfg.

I can fix "SSL: DH_KEY_TOO_SMALL" in another PR. The other issues are harder to fix.

./python -m test -v test_ssl >& test_ssl_verbose_36_master

Do you need a temporary login on one of my Pop!_OS computers, in order to test?

GH-21278 takes care of test failures related to DH params.

For the other test failures somebody has to backport df6ac7e2b82d921a6e9ff5571b40c6dbcf635581 to 3.6 and 3.5. I cannot promise that I'm able to find time to do the backport today.

Gotcha.  Thanks for looking into it for me.  I don't think the world is super anxious about getting 3.5.10rc1 so it's not a big huge deal.  But I will wait to hear back from you.  Thanks!

New changeset f52bf62fe12d46267e958f80dbe1f4425b55cd0f by Christian Heimes in branch '3.5':
bpo-41183: Update finite DH params to 3072 bits (#21278)
https://github.com/python/cpython/commit/f52bf62fe12d46267e958f80dbe1f4425b55cd0f

Any news?

Ping?

Does testing with the environment variable OPENSSL_CONF=/non-existing-file workaround the remaining issues?

> Does testing with the environment variable OPENSSL_CONF=/non-existing-file workaround the remaining issues?

Sadly, no.  I get the same failures whether or not that environment variable is set.  And I confirmed that the environment variable survives Python's testing harness, it doesn't get unset or overwritten.

Python 3.5.10 has been released, so I understand that this issue has been fixed. Thanks Christian Heimes for fixes ;-)

Nope, it's not fixed.

Python 3.5.10 is not the last 3.5 release?

* https://devguide.python.org/#status-of-python-branches
* https://www.python.org/dev/peps/pep-0478/

It depends on whether or not I get any more fixes for the rest of the month.  (Theoretically 3.5 support ends on Sep 13, but I decided to extend it to the end of the month.)

I filed this on July 1, so it's already been two months, and the developer who would handle this has stopped replying.  If I don't get a fix for this issue before the end of the month, then 3.5.10 will be the last release of 3.5 and this will simply go unfixed.

A day and a half to go!  Again, assuming that this won't be fixed and 3.5 will go EOL without supporting this year's Linux distro updates.