Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't create default SSLContext if ssl module isn't present #6724

Merged
merged 1 commit into from
May 29, 2024

Conversation

nateprewitt
Copy link
Member

This PR is to address a recent regression in Emscripten support for urllib3. We began unilaterally creating an SSLContext without consideration for Python versions built without an ssl module. This is handled in urllib3 but missed in our usage of create_urllib3_context.

This PR expands on the fix in #6716 by also evaluating both the presence of the ssl module before creating and setting the default SSLContext.


cert_reqs = "CERT_REQUIRED"
if verify is False:
cert_reqs = "CERT_NONE"
elif verify is True and not has_poolmanager_ssl_context:
elif verify is True and should_use_default_ssl_context:
Copy link
Contributor

Choose a reason for hiding this comment

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

Missed this earlier but do we need any logic for verify=True without a condition here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Are you asking about the behavior if verify is True but should_use_default_ssl_context is False? This was a no-op prior to #6655 which fellback to letting the SSLContext be created when fetching the connection from the pool. _ssl_wrap_socket_and_match_hostname handles this for us, so I don't know if there's any additional concern from our previous behavior unless I'm missing part of the question.

Copy link
Contributor

Choose a reason for hiding this comment

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

Makes sense. I've a terrible headache so just looking at the branches and concerned about missing something is all.

Copy link
Member Author

Choose a reason for hiding this comment

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

Nope, that's a good call out. I'll give it one more look before merging but I think we're ok for that case.

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, looking again, not on a phone, and without a migraine, I see the cert_reqs = "CERT_REQUIRED" line on L110 that I clearly wrote, and which is what I was thinking we may want to be concerned about. So, I'm not nearly as worried.


cert_reqs = "CERT_REQUIRED"
if verify is False:
cert_reqs = "CERT_NONE"
elif verify is True and not has_poolmanager_ssl_context:
elif verify is True and should_use_default_ssl_context:
Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, looking again, not on a phone, and without a migraine, I see the cert_reqs = "CERT_REQUIRED" line on L110 that I clearly wrote, and which is what I was thinking we may want to be concerned about. So, I'm not nearly as worried.


cert_reqs = "CERT_REQUIRED"
if verify is False:
cert_reqs = "CERT_NONE"
elif verify is True and not has_poolmanager_ssl_context:
elif verify is True and should_use_default_ssl_context:
pool_kwargs["ssl_context"] = _preloaded_ssl_context
elif isinstance(verify, str):
if not os.path.isdir(verify):
Copy link
Contributor

Choose a reason for hiding this comment

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

Looking at this again with something of a performance mindset, do we want to cache somehow lookups to isdir? I'm not sure this hurts us at all, but just thinking about things that could slow us down in certain cases now. (Not for this pull request, just putting it out there)

Copy link
Member Author

Choose a reason for hiding this comment

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

That seems like a reasonable optimization, I guess we'd need to check how much time we're actually spending on the dir check. I assume we'll get feedback if we have cases where this is a bottleneck.

@nateprewitt nateprewitt merged commit e188799 into main May 29, 2024
49 checks passed
@nateprewitt nateprewitt deleted the ssl_optimization branch May 29, 2024 15:23
@nateprewitt nateprewitt mentioned this pull request May 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants