…thonGH-25309)Signed-off-by: Christian Heimes <christian@python.org>(cherry picked from commit6f37ebc)Co-authored-by: Christian Heimes <christian@python.org>

…thonGH-25309)Signed-off-by: Christian Heimes <christian@python.org>(cherry picked from commit6f37ebc)Co-authored-by: Christian Heimes <christian@python.org>

…-25309)Signed-off-by: Christian Heimes <christian@python.org>(cherry picked from commit6f37ebc)Co-authored-by: Christian Heimes <christian@python.org>

…-25309)Signed-off-by: Christian Heimes <christian@python.org>(cherry picked from commit6f37ebc)Co-authored-by: Christian Heimes <christian@python.org>

…thonGH-25309)

pythonGH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a commentthat it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.That option causes OpenSSL to treat transport EOF as the same asclose_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually hasdistinct SSLEOFError and SSLZeroReturnError exceptions. (The latter isusually mapped to a zero return from read.) In OpenSSL 1.1.1, the sslmodule would raise them for transport EOF and close_notify,respectively. In OpenSSL 3.0, both act like close_notify.Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READINGand mapping that to the other exception type.There doesn't seem to have been any unit test of this error, so fill inthe missing one. This had to be done with the BIO path because it'sactually slightly tricky to simulate a transport EOF with Python's fdbased APIs. (If you instruct the server to close the socket, it getsconfused, probably because the server's SSL object is still referencingthe now dead fd?)

GH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a commentthat it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.That option causes OpenSSL to treat transport EOF as the same asclose_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually hasdistinct SSLEOFError and SSLZeroReturnError exceptions. (The latter isusually mapped to a zero return from read.) In OpenSSL 1.1.1, the sslmodule would raise them for transport EOF and close_notify,respectively. In OpenSSL 3.0, both act like close_notify.Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READINGand mapping that to the other exception type.There doesn't seem to have been any unit test of this error, so fill inthe missing one. This had to be done with the BIO path because it'sactually slightly tricky to simulate a transport EOF with Python's fdbased APIs. (If you instruct the server to close the socket, it getsconfused, probably because the server's SSL object is still referencingthe now dead fd?)

…5495)pythonGH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a commentthat it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.That option causes OpenSSL to treat transport EOF as the same asclose_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually hasdistinct SSLEOFError and SSLZeroReturnError exceptions. (The latter isusually mapped to a zero return from read.) In OpenSSL 1.1.1, the sslmodule would raise them for transport EOF and close_notify,respectively. In OpenSSL 3.0, both act like close_notify.Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READINGand mapping that to the other exception type.There doesn't seem to have been any unit test of this error, so fill inthe missing one. This had to be done with the BIO path because it'sactually slightly tricky to simulate a transport EOF with Python's fdbased APIs. (If you instruct the server to close the socket, it getsconfused, probably because the server's SSL object is still referencingthe now dead fd?)(cherry picked from commit420bbb7)Co-authored-by: David Benjamin <davidben@google.com>

…5495)pythonGH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a commentthat it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.That option causes OpenSSL to treat transport EOF as the same asclose_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually hasdistinct SSLEOFError and SSLZeroReturnError exceptions. (The latter isusually mapped to a zero return from read.) In OpenSSL 1.1.1, the sslmodule would raise them for transport EOF and close_notify,respectively. In OpenSSL 3.0, both act like close_notify.Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READINGand mapping that to the other exception type.There doesn't seem to have been any unit test of this error, so fill inthe missing one. This had to be done with the BIO path because it'sactually slightly tricky to simulate a transport EOF with Python's fdbased APIs. (If you instruct the server to close the socket, it getsconfused, probably because the server's SSL object is still referencingthe now dead fd?)(cherry picked from commit420bbb7)Co-authored-by: David Benjamin <davidben@google.com>

…5495)pythonGH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a commentthat it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.That option causes OpenSSL to treat transport EOF as the same asclose_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually hasdistinct SSLEOFError and SSLZeroReturnError exceptions. (The latter isusually mapped to a zero return from read.) In OpenSSL 1.1.1, the sslmodule would raise them for transport EOF and close_notify,respectively. In OpenSSL 3.0, both act like close_notify.Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READINGand mapping that to the other exception type.There doesn't seem to have been any unit test of this error, so fill inthe missing one. This had to be done with the BIO path because it'sactually slightly tricky to simulate a transport EOF with Python's fdbased APIs. (If you instruct the server to close the socket, it getsconfused, probably because the server's SSL object is still referencingthe now dead fd?)

…#103006)GH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a commentthat it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.That option causes OpenSSL to treat transport EOF as the same asclose_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually hasdistinct SSLEOFError and SSLZeroReturnError exceptions. (The latter isusually mapped to a zero return from read.) In OpenSSL 1.1.1, the sslmodule would raise them for transport EOF and close_notify,respectively. In OpenSSL 3.0, both act like close_notify.Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READINGand mapping that to the other exception type.There doesn't seem to have been any unit test of this error, so fill inthe missing one. This had to be done with the BIO path because it'sactually slightly tricky to simulate a transport EOF with Python's fdbased APIs. (If you instruct the server to close the socket, it getsconfused, probably because the server's SSL object is still referencingthe now dead fd?)(cherry picked from commit420bbb7)Co-authored-by: David Benjamin <davidben@google.com>

…#103007)GH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a commentthat it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.That option causes OpenSSL to treat transport EOF as the same asclose_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually hasdistinct SSLEOFError and SSLZeroReturnError exceptions. (The latter isusually mapped to a zero return from read.) In OpenSSL 1.1.1, the sslmodule would raise them for transport EOF and close_notify,respectively. In OpenSSL 3.0, both act like close_notify.Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READINGand mapping that to the other exception type.There doesn't seem to have been any unit test of this error, so fill inthe missing one. This had to be done with the BIO path because it'sactually slightly tricky to simulate a transport EOF with Python's fdbased APIs. (If you instruct the server to close the socket, it getsconfused, probably because the server's SSL object is still referencingthe now dead fd?)(cherry picked from commit420bbb7)Co-authored-by: David Benjamin <davidben@google.com>

…5495)pythonGH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a commentthat it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.That option causes OpenSSL to treat transport EOF as the same asclose_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually hasdistinct SSLEOFError and SSLZeroReturnError exceptions. (The latter isusually mapped to a zero return from read.) In OpenSSL 1.1.1, the sslmodule would raise them for transport EOF and close_notify,respectively. In OpenSSL 3.0, both act like close_notify.Fix this by, instead, just detecting SSL_R_UNEXPECTED_EOF_WHILE_READINGand mapping that to the other exception type.There doesn't seem to have been any unit test of this error, so fill inthe missing one. This had to be done with the BIO path because it'sactually slightly tricky to simulate a transport EOF with Python's fdbased APIs. (If you instruct the server to close the socket, it getsconfused, probably because the server's SSL object is still referencingthe now dead fd?)

…thonGH-25309)Signed-off-by: Christian Heimes <christian@python.org>(cherry picked from commit6f37ebc)Co-authored-by: Christian Heimes <christian@python.org>

…thonGH-25309)Signed-off-by: Christian Heimes <christian@python.org>(cherry picked from commit6f37ebc)Co-authored-by: Christian Heimes <christian@python.org>

…thonGH-25309)Signed-off-by: Christian Heimes <christian@python.org>(cherry picked from commit6f37ebc)Co-authored-by: Christian Heimes <christian@python.org>