Skip to content

Conversation

@nateprewitt
Copy link
Member

This PR reverts the changes from #6667 to the previous behavior. Due to the number of edge cases and concurrency issues we've encountered with this change, we've decided the benefit doesn't currently outweigh the pain to existing infrastructure. We've iterated on a few tries to keep this functionality in place, but are still receiving reports of novel issues with this behavior.

We may be able to revisit this in a later version of Requests but we'll need a much more comprehensive test plan.

@nateprewitt nateprewitt force-pushed the remove_cached_sslcontext branch from ce40c46 to d520f46 Compare July 18, 2024 18:01
@stianjensen
Copy link

Is this still planned to be reverted?

@Conobi
Copy link

Conobi commented Jun 2, 2025

I would also suggest to revert it ASAP.
This unsafe caching can make some applications vulnerable to DOS attack when using mTLS authentication, causing Python to crash.
In its current version, requests cannot be used safely in mTLS scenarios.

@dkliban
Copy link

dkliban commented Jun 13, 2025

@sigmavirus24 I applied this PR as a patch to my server and it stopped the core dumps i was experiencing. When is this going to be merged and released?

@nateprewitt
Copy link
Member Author

@dkliban It should go out with the next release. We'll update once we have a clearer timeline, we'll see what we can do next week.

@dkliban
Copy link

dkliban commented Jun 16, 2025

@nateprewitt Thank you for merging! Looking forward to the release!

@dkliban
Copy link

dkliban commented Jun 26, 2025

@nateprewitt any updates on when this will be released?

bmwiedemann pushed a commit to bmwiedemann/openSUSE that referenced this pull request Jul 15, 2025
https://build.opensuse.org/request/show/1293092
by user dgarcia + anag_factory
- Add revert-caching-default-sslcontext.patch upstream patch to avoid
  problems with certificate caching in sslcontext.
  bsc#1246104, gh#psf/requests#6767
@rittneje

This comment has been minimized.

@jonyscathe
Copy link

I had hoped that this would also fix #6647 but on my local testing it doesn't seem that it has. Should this PR have fixed that? Or was that one caused by something else?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

7 participants