SNOW-843716: Cryptography library cleanup

[geofft]

What is the current behavior?

Hi! It looks like the connector depends on five cryptography-related packages, asn1crypto, cryptography, oscrypto, pyOpenSSL, and pycryptodome.

Would there be interest in consolidating these as far as possible? I think most of this can be consolidated onto just the cryptography library. I'd be happy to contribute a pull request, just wanted to check with you all first. The one I'm least sure about is asn1crypto, but it looks like that one's being used for OCSP support, which cryptography has high-level functions for. From a quick look, everything else seems like stuff I'm pretty sure cryptography can handle.

What is the desired behavior?

Ideally, the connector should depend on a single, well-maintained cryptography library.

How would this improve snowflake-connector-python?

This would reduce maintenance overhead and security risk.

References and other background

No response

[sfc-gh-spanaite]

Thanks for this @geofft.
I think it should fine to submit a PR and we can have a look at it after.
Any thoughts @sfc-gh-achandrasekaran and @sfc-gh-mkeller?

[waltervos]

If you can get rid of urllib3.contrib.pyopenssl this way, that should also solve #1586

[kpark-hrp]

Getting rid of oscrypto with #1616 will be super nice because from oscrypto import asymmetric attempts to import OpenSSL shared libraries which breaks simple Python containers without OpenSSL/LibreSSL.

Wondering if #1616 can be expedited as it will resolve our pain point? @sfc-gh-spanaite

[DustinMoriarty]

oscrypto has had this very serious bug since August.

wbond/oscrypto#76

The fix was merged. However, the fix was never released to pypi. An issue was raised to request a release. However, there has been no response.

wbond/oscrypto#78

The repo has had almost no commits since then. The repo does not appear to be well supported. It could be that oscrypto is a case of an open source library that just does not have enough maintainers to make it reliable.

[munir0b0t]

This is also affecting snowsql client. It doesn't start up on Debian 12 Bookworm because of the issues with oscrypto.

[jfo8001]

Debian 12 Bookworm just busted for us too - very hard to work around this issue in the various libraries we use. Would be great to remove dependency on oscrypto.

I have mentioned this in a separate bug, which feels more urgent
#1767

[munir0b0t]

I managed to get my Debian 12 docker containers working by adding apt-mark hold openssl libssl3 before installing openssl or any package that depends on openssl like git. Not ideal, but might be good enough until the issue is fixed properly. I also created a case with Snowflake Support for this, so hopefully there's some more eyes on this.

[sfc-gh-aling]

thanks for all the feedback, we're going to remove the dependency on oscrpyto and pycryptodomex in our next connector release and we will do a release for snowsql accordingly.

I have created an announcement issue: #1781

[sfc-gh-aling]

we have released v3.4.0 removing oscrypto and pycryptodomex, thank you!