[3.14] gh-134698: Hold a lock when the thread state is detached in ssl (GH-134724)#137107
[3.14] gh-134698: Hold a lock when the thread state is detached in ssl (GH-134724)#137107ZeroIntensity merged 3 commits intopython:3.14from
ssl (GH-134724)#137107Conversation
… in `ssl` (pythonGH-134724) Lock when the thread state is detached. (cherry picked from commit e047a35) Co-authored-by: Peter Bierma <[email protected]> Co-authored-by: Gregory P. Smith <[email protected]>
ZeroIntensity
left a comment
There was a problem hiding this comment.
Thanks for doing the backport.
|
@hugovk - up to you when this should merge for 3.14. it is a bug, but it has been around for a while. Traditionally RMs pick and choose what go in an RC to minimize changes to reduce release surprises, leaving whatever they deem less urgent as bug fixes for the .1 release. Your call. |
|
intentionally not marking this as a release blocker as it doesn't seem that fundamental. |
I'm not sure I understand the basis for this reasoning @gpshead, as the direct consequence of this is that any application that takes advantage of concurrency (for e.g FastAPI/Django Channels/LiteStart/Celery with Eventelet) and uses mTLS authentication for calling an API (for example with Requests, which hasn't released a fix yet), is then vulnerable. As the mTLS authentication pattern is very common in banking/finance/governemental apps, it means that Python apps in these orgs are very likely to vulnerable to DOS attacks. It was the case for our app, I'm sure it's the case for a lot of others one in the nature. |
|
As of a consequence of not backporting it @gpshead, is that no app can be fixed (unless a manual monkeypatch) until the Requests nor Python 3.14 release. It means thousands of apps vulnerables in the nature to a very simple DOS attack until then. |
|
rationale: The bug this fixes has existed for a very long time and seems likely to be present in all basically all Python releases. Not something that needs to be a priority release blocker during our release candidate phase. ie: It isn't a regression in behavior or compatibility present only in 3.14. If you want it to be considered a security bug, please report it with some form of proof of concept of being able to trigger the hang or crash remotely to [email protected]. (without that, we won't be back porting this to anything earlier than 3.13) |
|
Please hold off on merging this until #137583 has been addressed. |
|
yay getting lucky! :) |
This solves a deadlock when a socket is blocked while waiting on data, which ended up causing a major regression in 3.13.6 (see pythongh-137583).
|
🤖 New build scheduled with the buildbot fleet by @ZeroIntensity for commit 8ff02f8 🤖 Results will be shown at: If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
|
I've pushed the fix from #137588 to prevent the deadlocks from hitting 3.14. This is now safe to merge (assuming the buildbots pass), but I would totally understand if Hugo doesn't want to touch this with a ten-foot pole. |
|
Yeah, let's wait for 3.14.1 for this one. |
|
It seems 3.13.7 went well with the fix, so let's go ahead and land this for 3.14.1. Let's hope we don't break any major downstream packages this time! |
Lock when the thread state is detached.
(cherry picked from commit e047a35)