Repository navigation
SNOW-3894391: pyOpenSSL>=22.0.0 floor accepts a version with an unbounded cryptography dependency #2990
Description
Python version
3.10.x
Operating system and processor architecture
Linux-x86_64 (GitHub Actions ubuntu runner)
Installed packages
Minimal repro set, not a full environment freeze (the bug reproduces from just these two):
pyOpenSSL==22.0.0
cryptography>=44What did you do?
pip install "pyOpenSSL==22.0.0" "cryptography>=44"
python -c "import urllib3.contrib.pyopenssl"
`snowflake-connector-python<4.4.0` depends on `pyOpenSSL<26.0.0,>=22.0.0`. `pyOpenSSL==22.0.0` itself depends on `cryptography>=35.0` with no upper bound.
A resolver that picks `snowflake-connector-python` without other constraints in the environment can land on exactly - pair and both packages install cleanly, satisfying every stated constraint.
We hit this for real in Apache Airflow's CI run: https://github.com/apache/airflow/actions/runs/30980932281/job/92228997439?pr=71103
A few compatibility jobs resolve providers unconstrained, and once nothing else in the dependency set capped cryptography, the resolver picked `pyOpenSSL==22.0.0` alongside a current cryptography and the environment stopped being importable.What did you expect to see?
pip install should not produce an environment where import urllib3.contrib.pyopenssl fails.
pyOpenSSL==22.1.0 is the first release that bounds cryptography correctly (cryptography<39,>=38.0.0), and every release after it carries a matching bound.
Raising the connector's floor to pyOpenSSL>=22.1.0 on the <4.4.0 line excludes the one broken version and fixes this without requiring the jump to cryptography>=46.0.5 that snowflake-connector-python>=4.4.0 demands.
We worked around it downstream by pinning pyOpenSSL>=22.1.0 directly in our own provider (apache/airflow#71145), but the floor here is the actual source.
Activity
[-]`pyOpenSSL>=22.0.0` floor accepts a version with an unbounded `cryptography` dependency[/-][+]SNOW-3894391: `pyOpenSSL>=22.0.0` floor accepts a version with an unbounded `cryptography` dependency[/+]sfc-gh-sghosh commentedon Aug 11, 2026
Hi @amoghrajesh ,
Thanks for raising the issue.
The broken floor exists only in v4.0.0; v4.1.0+ already pin pyOpenSSL>=24.0.0. So could you upgrade to v4.1.0, that should resolve the unimportable-environment problem without requiring cryptography>=46.0.5.