bpo-34759: Fix error handling in ssl 'unwrap()'#9468
Conversation
OpenSSL follows the convention that whenever you call a function, it returns an error indicator value; and if this value is negative, then you need to go look at the actual error code to see what happened. Commit c6fd1c1 introduced a small mistake in _ssl__SSLSocket_shutdown_impl: instead of checking whether the error indicator was negative, it started checking whether the actual error code was negative, and it turns out that the error codes are never negative. So the effect was that 'unwrap()' lost the ability to raise SSL errors.
|
The commit that introduced this bug was backported to 3.6 and 3.7, so this needs to be too; but, I believe we caught it before either of those branches released, so no need for a news entry. |
vstinner
left a comment
There was a problem hiding this comment.
LGTM, but I would prefer that someone else also reviews the change. Thanks for adding more tests :-)
zooba
left a comment
There was a problem hiding this comment.
The fix is good. I can follow the test just fine and it also looks good, but I have to take it on faith that it's testing the scenario :)
|
I did check that the test fails without the fix. |
|
Thanks @njsmith for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7. |
OpenSSL follows the convention that whenever you call a function, it returns an error indicator value; and if this value is negative, then you need to go look at the actual error code to see what happened. Commit c6fd1c1 introduced a small mistake in _ssl__SSLSocket_shutdown_impl: instead of checking whether the error indicator was negative, it started checking whether the actual error code was negative, and it turns out that the error codes are never negative. So the effect was that 'unwrap()' lost the ability to raise SSL errors. https://bugs.python.org/issue34759 (cherry picked from commit c0da582) Co-authored-by: Nathaniel J. Smith <njs@pobox.com>
|
GH-9491 is a backport of this pull request to the 3.7 branch. |
|
Sorry, @njsmith, I could not cleanly backport this to |
OpenSSL follows the convention that whenever you call a function, it returns an error indicator value; and if this value is negative, then you need to go look at the actual error code to see what happened. Commit c6fd1c1 introduced a small mistake in _ssl__SSLSocket_shutdown_impl: instead of checking whether the error indicator was negative, it started checking whether the actual error code was negative, and it turns out that the error codes are never negative. So the effect was that 'unwrap()' lost the ability to raise SSL errors. https://bugs.python.org/issue34759. (cherry picked from commit c0da582) Co-authored-by: Nathaniel J. Smith <njs@pobox.com>
|
GH-9492 is a backport of this pull request to the 3.6 branch. |
OpenSSL follows the convention that whenever you call a function, it returns an error indicator value; and if this value is negative, then you need to go look at the actual error code to see what happened. Commit c6fd1c1 introduced a small mistake in _ssl__SSLSocket_shutdown_impl: instead of checking whether the error indicator was negative, it started checking whether the actual error code was negative, and it turns out that the error codes are never negative. So the effect was that 'unwrap()' lost the ability to raise SSL errors. https://bugs.python.org/issue34759 (cherry picked from commit c0da582) Co-authored-by: Nathaniel J. Smith <njs@pobox.com>
) OpenSSL follows the convention that whenever you call a function, it returns an error indicator value; and if this value is negative, then you need to go look at the actual error code to see what happened. Commit c6fd1c1 introduced a small mistake in _ssl__SSLSocket_shutdown_impl: instead of checking whether the error indicator was negative, it started checking whether the actual error code was negative, and it turns out that the error codes are never negative. So the effect was that 'unwrap()' lost the ability to raise SSL errors. https://bugs.python.org/issue34759. (cherry picked from commit c0da582) Co-authored-by: Nathaniel J. Smith <njs@pobox.com> https://bugs.python.org/issue34759
OpenSSL follows the convention that whenever you call a function, it
returns an error indicator value; and if this value is negative, then
you need to go look at the actual error code to see what happened.
Commit c6fd1c1 introduced a small mistake in
_ssl__SSLSocket_shutdown_impl: instead of checking whether the error
indicator was negative, it started checking whether the actual error
code was negative, and it turns out that the error codes are never
negative. So the effect was that 'unwrap()' lost the ability to raise
SSL errors.
https://bugs.python.org/issue34759