tree 2e94b5f4b976ea0bd5af2a3ec679a1e1fe7d8657
parent b28f919007439b48a1d00d54134d7b020a683cda
author Miss Islington (bot) <31488909+miss-islington@users.noreply.github.com> 1679926441 -0700
committer GitHub <noreply@github.com> 1679926441 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJkIaSpCRBK7hj4Ov3rIwAAEHIIAD1GBqMQNYPWlNaIw27rdAeL
 iy0nZ7ebqmzZ4lTwbxlFFsTrkkMLEWgJWn0otWjnT6LKxj8A1yFnr18EdwPFLFqu
 gcj6YbqeG1T1bl2ovEbGiDxV45QvdHxEn4s2nrtFN5Ii9HliQpT1Acjrgx76BhRy
 jJ7Eg3xOEFmqk89FKtBj2hNuXYGSTAgcdpiujP8BwPUNkoT/R6v/liyX2qSIb17i
 GWb7k79B30QkMzIYbsFRKPiDpBJLhhSnvK9aFU85JEGjA9LMh+8qMqhxMECQQVlr
 QvZgPr7eg8UpgF6CX303hBQWChFZHj0LndOpIldE69HpXgBhFQXq0HYxOwEKhGs=
 =JkbY
 -----END PGP SIGNATURE-----
 

[3.11] GH-95494: Fix transport EOF handling in OpenSSL 3.0 (GH-95495) (#103006)

GH-25309 enabled SSL_OP_IGNORE_UNEXPECTED_EOF by default, with a comment
that it restores OpenSSL 1.1.1 behavior, but this wasn't quite right.
That option causes OpenSSL to treat transport EOF as the same as
close_notify (i.e. SSL_ERROR_ZERO_RETURN), whereas Python actually has
distinct SSLEOFError and SSLZeroReturnError exceptions. (The latter is
usually mapped to a zero return from read.) In OpenSSL 1.1.1, the ssl
module 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_READING
and mapping that to the other exception type.

There doesn't seem to have been any unit test of this error, so fill in
the missing one. This had to be done with the BIO path because it's
actually slightly tricky to simulate a transport EOF with Python's fd
based APIs. (If you instruct the server to close the socket, it gets
confused, probably because the server's SSL object is still referencing
the now dead fd?)
(cherry picked from commit 420bbb783b43216cc897dc8914851899db37a31d)

Co-authored-by: David Benjamin <davidben@google.com>