Yes, it is safe. I wonder, why SSL_CTX_set_default_verify_paths does not release the GIL in the first place. Probably an oversight. It is a very costly call that performs I/O and expensive computational tasks. It loads all root CA certificates from disk, parses + validates them, and puts them into a lookup data structure.

You can also optimize the code and use a single SSLContext object for all network code. It is safe to share a single instance across threads if you don't modify the object (load more certs, change verification parameters, options, etc.).

You can also optimize the code and use a single SSLContext object for all network code. It is safe to share a single instance across threads if you don't modify the object (load more certs, change verification parameters, options, etc.).

Good to know; thanks! Even with the GIL-related hitches fixed, that would probably be worth it for me to do to shave that time off of individual network round trips. I'm assuming this would be done by explicitly passing in the SSLContext for each particular use? Or is there any higher level way to get things to share a single context by default?

And on a related note, is there any clean way to point all contexts at a root cert file by default? Since Android doesn't seem to have certs in a consistent place I'm bundling ones from the Python certifi package and using the SSL_CERT_FILE env var to point SSL at them, which gets them picked up by all contexts, but I didn't know if there's a more 'correct' way to do that sort of thing.

All stdlib network modules accept a context or ssl_context argument, e.g. urllib.request.urlopen(context=...). You have to pass a context explicitly.

I recommend that users always create a context with ssl.create_default_context(). It will either load certificates from default location (and use SSL_CERT_FILE) or you can pass arguments to load a cafile or capath instead. You can load additional trust anchors with ctx.load_verify_locations().

Ok; sounds good. I'll just pass in an explicit shared context created from ssl.create_default_context() in places I want to speed up then. And it sounds like SSL_CERT_FILE is the right way to go to get said default contexts doing the right thing. 👍

One obscure note in case its helpful: on my Android OpenSSL build, SSL_CERT_FILE wasn't actually getting read by default. OpenSSL does a ossl_safe_getenv() call which was disallowing its use for some reason. But ssl.get_default_verify_paths() in Python incorrectly listed it as a verify path. I don't know if it would be possible or worth the energy to have ssl.get_default_verify_paths() tap into that same logic to keep things consistent, but I just thought I'd mention it. (And I wound up just forcing my Android SSL build to always accept env vars to get it working in my case).