-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
Move _get_connection to get_connection_with_tls_context #6710
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, only had one suggestion that might require a new test.
A small update about the minimum pass-through code for someone who will stumble upon this - don’t forget to def get_connection_with_tls_context(self, request, verify, proxies=None, cert=None):
return self.get_connection(request.url, proxies) |
…ocket psf/requests#6710 msabramo/requests-unixsocket#72 Signed-off-by: Simon Deziel <[email protected]>
requests 2.32 security fix recommends a fix: psf/requests#6710 This was proposed (but not yet merged) to requests-unixsocket in: msabramo/requests-unixsocket#72 Signed-off-by: Simon Deziel <[email protected]>
Thank you @kdymov! I've fixed the initial example as well. |
I'm having some issues upgrading to requests 2.32 which I think are related to this change, but I can't quite figure out how I'd need to upgrade my code. My HTTPAdapter subclass basically overrides the TLS context to allow weak DH ciphers: class AFIPAdapter(HTTPAdapter):
"""An adapter with reduced security so it'll work with AFIP."""
def init_poolmanager(self, *args, **kwargs) -> PoolManager:
context = create_urllib3_context(ciphers=CIPHERS)
kwargs["ssl_context"] = context
return super().init_poolmanager(*args, **kwargs)
def proxy_manager_for(self, *args, **kwargs) -> ProxyManager:
context = create_urllib3_context(ciphers=CIPHERS)
kwargs["ssl_context"] = context
return super().proxy_manager_for(*args, **kwargs) With Do you have any guidance? |
I'm also a bit confused by |
@WhyNotHugo You may be hitting a separate issue with |
2.32.3 raises an entirely different exception:
|
Looks like I need to add |
We may not be loading the cert bundle the same as we were previously. Would you mind opening a new issue with a minimal reproduction (the adapter you have above is likely fine). If you can also include the info we request from help, and if you're working behind a proxy when this happens. That'd be helpful, thanks! |
…e#1583) Requests prior to 2.32.3 always loaded the default (system-wide) set of trusted certificates into custom SSL contexts. 2.32.3 no longer does. This has broken a lot of users, but the fix is moving slowly upstream due to security considerations - see psf/requests#6730 and psf/requests#6731 . As suggested at psf/requests#6710 (comment) this can be worked around by explicitly loading the default certificates into the context. We check the method exists before calling it just to be safe, but I'm pretty sure it's been there as long as this interface has existed. Signed-off-by: Adam Williamson <[email protected]>
…e#1583) Requests prior to 2.32.3 always loaded the default (system-wide) set of trusted certificates into custom SSL contexts. 2.32.3 no longer does. This has broken a lot of users, but the fix is moving slowly upstream due to security considerations - see psf/requests#6730 and psf/requests#6731 . As suggested at psf/requests#6710 (comment) this can be worked around by explicitly loading the default certificates into the context. We check the method exists before calling it just to be safe, but I'm pretty sure it's been there as long as this interface has existed. Signed-off-by: Adam Williamson <[email protected]>
…e#1583) Requests prior to 2.32.3 always loaded the default (system-wide) set of trusted certificates into custom SSL contexts. 2.32.3 no longer does. This has broken a lot of users, but the fix is moving slowly upstream due to security considerations - see psf/requests#6730 and psf/requests#6731 . As suggested at psf/requests#6710 (comment) this can be worked around by explicitly loading the default certificates into the context. We check the method exists before calling it just to be safe, it was added in Python 3.4. Signed-off-by: Adam Williamson <[email protected]>
#1596) * Explicitly load default certificates when creating SSL context (#1583) Requests prior to 2.32.3 always loaded the default (system-wide) set of trusted certificates into custom SSL contexts. 2.32.3 no longer does. This has broken a lot of users, but the fix is moving slowly upstream due to security considerations - see psf/requests#6730 and psf/requests#6731 . As suggested at psf/requests#6710 (comment) this can be worked around by explicitly loading the default certificates into the context. We check the method exists before calling it just to be safe, it was added in Python 3.4. Signed-off-by: Adam Williamson <[email protected]> * Drop the upper bound on the requests dependency again As we can now work with requests 2.32.3+, we no longer need this pin. Signed-off-by: Adam Williamson <[email protected]> --------- Signed-off-by: Adam Williamson <[email protected]>
This PR is meant to provide a new publicly supported api
get_connection_with_tls_context
to better facilitate custom adapters with our recent fix for CVE-2024-35195.As described here, we will be deprecating the existing
get_connection
API, and custom adapters will need to migrate their existingget_connection
implementations to useget_connection_with_tls_context
. Below is a very simple implementation that will get projects relying on a customget_connection
implementation unblocked.However, we strongly recommend maintainers evaluate if their custom
get_connection
is subject to the same issues as the CVE above and make appropriate changes as needed.Minimum new code to work as a pass-through
This will be backwards compatible between versions of Requests.