Paul Kehrer

I think I already answered the question in my previous reply, but no updates on getting this fixed. Someone has to step forward to do the work 😄

Yes we would take a PR for this, although it would be desirable for this to be consistent across the API.

In the past I believe people have used [service_identity.pyopenssl.verify_hostname](https://service-identity.readthedocs.io/en/stable/api.html#service_identity.pyopenssl.verify_hostname) to handle this case, but now that OpenSSL properly includes a way to validate it makes sense to potentially expose it...

Ah thanks for the reminder Christian. I'll put that note over on the cryptography PR as well, sigh.

The next release of pyca/cryptography will be linked against OpenSSL 1.1.1. I'll go ahead and add the bindings for cryptography, but adding the feature itself in pyOpenSSL is dependent upon...

Is there a way we can cover this with a test? And is `SSL_MODE_ENABLE_PARTIAL_WRITE` being set anywhere?

requests will use pyOpenSSL by default when it is present in an environment, so that's why you're seeing this. You can tell requests not to do that with `requests.packages.urllib3.contrib.pyopenssl.extract_from_urllib3`. However,...

Well that's all the latest versions (which is really all I was curious about). It would definitely be good to improve pyOpenSSL's performance here but I'm not sure if anyone...

If you import that and call it **after** importing requests it should be fine.

@begoldsm `urllib3.contrib.pyopenssl.extract_from_urllib3` should do it in that case. We can all shake a fist at the Debian project for their vendoring policy there...