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

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 security@python.org. (without that, we won't be back porting this to anything earlier than 3.13)