Possibility to register truststore more globally

[guerda]

This is more a question/discussion than an issue.
I'm using a lot of Python libraries, which build on urllib3, aiohttp or requests. In seldom cases, I am able to get the pool manager or SSL context to inject truststore's context into it.

Is there an option to inject truststore more globally, so that dependent libraries use it?
Here are some examples:

• overpass uses urllib3 and requests for tests
• elasticsearch uses urllib3

[sethmlarson]

For this you mean a way to patch the ssl module's SSLContext so it's automatically used? I know a few other similar libraries do that, especially because SSLContext is usually buried deep in other dependencies and not exposed through every API.

[guerda]

Yeah, I have no idea if that is possible from truststore or if it needs adaptions of those libs one by one.

[JonasR]

I would like to second that this would be highly valuable. I don't know how the approach of truststore differs between that of pip-system-certs but using the latter, requests will also work if I use a third-party library that internally makes use of requests (and most likely does not expose the API so that I could make it work with truststore).

[pfeigl]

This would be really important. Being able to just install truststore and having all third-party code work would be so important.

[andrewleech]

Author of pip-system-certs here, to be clear it's a rather awful, fragile hack! In fact I believe I need to update it to support changes in the latest urllib.

I use wrapt library and hook patterns it provides to auto-run monkey patching functions whenever (just before) requests and similar are imported.

The hooking mechanism is a bit of a pain though and can break in weird and wonderful ways, eg. After installing pip-system-certs if wrapt is uninstalled it used to break pip completely!

That being said, requests have been extremely resistant to changing their SSL scheme, regardless of how many hundreds of people request it over many years: psf/requests#2966
So until they bring in direct support for truststore, or some other clean way of injecting it is found, I'll continue hacking my way around the problem.

I'm pretty keen to rework pip-system-certs to use truststore though, might look for a cleaner way to patch it in based on #85

[andrewleech]

Ah, I only just properly reviewed how neat and thorough the existing global registration is!

import truststore
truststore.inject_into_ssl()

Is delightfully clean, though obviously only really works for code you own, not "fixing" other python apps to use your system certs.

The system I use to deal with this is autowrapt
https://pypi.org/project/autowrapt/
Which is discussed in detail here:
http://blog.dscpl.com.au/2015/04/automatic-patching-of-python.html?m=1

The long and short of it though, you can create a .pth file in the 'site-packages' directory with python code snippets that will be run at every python startup, before any scripts are run.

How would you feel about a package extras that includes such a pth fine that perhaps just runs those two above lines?
Eg. pip install truststore[globally]

I'm not sure if a more complex autowrapt hooking the import of urllib or other related libraries is really worth it, though there might be some benefit.

[sethmlarson]

@andrewleech The current method should work for most code you don't own as long as it's called early enough in the program's life, most libraries don't create SSLContexts in the global scope (unless you're aware of some that do? Lmk)

[andrewleech]

Hi @sethmlarson I'm referring more to it not working for third party python applications, eg. twine, python-gitlab cli, pip (ignoring the truststore integration option built in there).

I just mean you currently need to own at least the top level python script to run the truststore function before running/importing other code.