Fix incompatibility issue between OCSP dependencies

[oh2fih]

PyOpenSSL < 23.2.0 is incompatible with cryptography >= 42.0.0; PyOpenSSL 23.2.0 stopped referencing X509_V_FLAG_NOTIFY_POLICY that was removed in cryptography 42.0.0. Using compatible minimum versions is an easy solution.

Ref. cve-search/cve-search#1099 (comment) & conda/conda#13619 (comment)

[oh2fih]

Another problem remains: if an older version of PyOpenSSL is already installed by anything else than pip install "pymongo[ocsp]", the ssl_support.py still defaults to using pymongo.pyopenssl_context over pymongo.ssl_context (standard library SSL). Instead of blindly importing pyOpenSSL, ssl_support.py should be able to check whether the installed version meets the requirements. Any suggestions on how this should be checked?

[ShaneHarvey]

As PyMongo is a library (not a standalone app) we aim for it to be installable+useable in as wide a range of environments as possible. That means we leave our dependencies as open as we can so bumping the minimum versions of pyopenssl/cryptography here goes against our practices. In this case, it is the user's responsibility to have a functioning install of pyopenssl.

Instead of blindly importing pyOpenSSL, ssl_support.py should be able to check whether the installed version meets the requirements. Any suggestions on how this should be checked?

I agree this is a problem. We will consider adding a feature to control when stdlib ssl or pyopenssl is used. I opened a feature request for the idea here: https://jira.mongodb.org/browse/PYTHON-4491

[oh2fih]

I can understand why this approach would be against your practices. I have another suggestion for handling the exception caused by this situation without interrupting the entire program available in #1669; it should be more backwards compatible. The feature request can be discussed in https://jira.mongodb.org/browse/PYTHON-4491 as the exception handling is not conflicting with the idea, but complementary.

[ShaneHarvey]

Thanks, #1669 looks like a good idea to me.