I don't see why a SSLSocket would raise an OSError on read()/write().

On ECONNRESET error, read() raises an SSLEOFError exception: seehttps://bugs.python.org/issue43921#msg394967

cc@tiran

It's based on old code from Antoine, seetest_wrong_cert_tls12 and commita6a4dc8.

It's based on old code from Antoine, see test_wrong_cert_tls12 and commit a6a4dc8.

I see. For test_wrong_cert_tls12(), SSLError or OSError is expected on connect(), not on read/write. There is a comment explaining the OSError:

# Expect either an SSL error about the server rejecting# the connection, or a low-level connection reset (which# sometimes happens on Windows)s.connect((HOST, server.port))

test_wrong_cert_tls13() is different because TLS 1.3 is different. The test doesn't expect any error on connect(), only on read() or write(). It also explained in a comment:

# TLS 1.3 perform client cert exchange after handshake

In short, test_wrong_cert_tls12() looks correct, and I now understand how test_wrong_cert_tls13() inheritedexcept OSError:. So I'm not convinced that it's ok to remove it :-)

This change makes the test more strict (check the exact error message). I'm not sure that it works well on all platforms and all supported OpenSSL versions. I prefer to not backport the change to 3.10. At least, not now.

Either keep 3.9 to 3.11 tests in sync or don't merge changes.

Thanks@vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10.
🐍🍒⛏🤖

Thanks@vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

Sorry@vstinner, I had trouble checking out the3.10 backport branch.
Please backport usingcherry_picker on command line.
cherry_picker 5c2191df9a21a3b3d49dd0711b8d2b92591ce82b 3.10

Sorry,@vstinner, I could not cleanly backport this to3.9 due to a conflict.
Please backport usingcherry_picker on command line.
cherry_picker 5c2191df9a21a3b3d49dd0711b8d2b92591ce82b 3.9

@vstinner please backport changes to 3.10 and 3.9. Tests should be kept in sync.