Skip to content

bpo-34759: Fix error handling in ssl 'unwrap()'#9468

Merged
miss-islington merged 1 commit into
python:masterfrom
njsmith:fix-34759
Sep 22, 2018
Merged

bpo-34759: Fix error handling in ssl 'unwrap()'#9468
miss-islington merged 1 commit into
python:masterfrom
njsmith:fix-34759

Conversation

@njsmith

@njsmith njsmith commented Sep 21, 2018

Copy link
Copy Markdown
Contributor

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

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.
@njsmith

njsmith commented Sep 21, 2018

Copy link
Copy Markdown
Contributor Author

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 vstinner left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but I would prefer that someone else also reviews the change. Thanks for adding more tests :-)

@1st1 1st1 requested a review from tiran September 21, 2018 18:35

@1st1 1st1 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd wait a day to allow @tiran review this too.

@zooba zooba left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

@njsmith

njsmith commented Sep 21, 2018

Copy link
Copy Markdown
Contributor Author

I did check that the test fails without the fix.

@tiran tiran left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fantastic, thanks Nathaniel!

@miss-islington miss-islington merged commit c0da582 into python:master Sep 22, 2018
@miss-islington

Copy link
Copy Markdown
Contributor

Thanks @njsmith for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7.
🐍🍒⛏🤖

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Sep 22, 2018
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>
@bedevere-bot

Copy link
Copy Markdown

GH-9491 is a backport of this pull request to the 3.7 branch.

@miss-islington

Copy link
Copy Markdown
Contributor

Sorry, @njsmith, I could not cleanly backport this to 3.6 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker c0da582b227f311126e278b5553a7fa89c79b054 3.6

@miss-islington miss-islington self-assigned this Sep 22, 2018
tiran pushed a commit to tiran/cpython that referenced this pull request Sep 22, 2018
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>
@bedevere-bot

Copy link
Copy Markdown

GH-9492 is a backport of this pull request to the 3.6 branch.

miss-islington added a commit that referenced this pull request Sep 22, 2018
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>
miss-islington pushed a commit that referenced this pull request Sep 22, 2018
)

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants