`SSLContext` recursion error strikes again (potential bug as well)

[cmin764]

Related to this older Issue, we started to encounter this problem through our robocorp libraries (where injection gets done -- so at CLI level, not library) and now I observe it even in our CI during the test runs. (while I couldn't reproduce locally on the same system and Python version)

1. Question is, did something change in the ssl.py so that this started to appear with the later Py3.10.x versions?
2. And why is the super class invoked like this: _original_super_SSLContext = super(_original_SSLContext, _original_SSLContext)? Even in the standard ssl module I see the same pattern when calling the verify_mode method. By looking at the docs we have the following:

   super(type, type2) -> bound super object; requires issubclass(type2, type)

   @verify_mode.setter
   def verify_mode(self, value):
       super(SSLContext, SSLContext).verify_mode.__set__(self, value)
   

   L.E.: That's all good, as expected. (as we get the super class of the first argument while passing the second for change)
3. Don't we have a bug here with this code (_api.py)?

   @verify_flags.setter
   def verify_flags(self, value: ssl.VerifyFlags) -> None:
       _original_super_SSLContext.verify_flags.__set__(  # type: ignore[attr-defined]
           self._ctx, value
       )
   

   as clearly we don't have .verify_flags available with PyPI.

[JonasR]

We are seeing the same issue when using truststore with requests and talking to some APIs, but not others. Haven't figured out yet what the determining factor is really.

However, it works if I pin requests = "==2.31.0" even with truststore = "==0.9.0", so maybe more of a requests bug? Related to https://github.com/psf/requests/pull/6731?

[sethmlarson]

Yeah this seems like a Requests bug, unfortunately. Going to close this issue.