Hi, I have been investigating why version 3.1-1 the python-cryptography source package (which builds the python3-cryptography binary package) was not migrating from Debian unstable to Debian testing. I determined that the reason was that python3-azure-cli depends on python3-cryptography << 3.0.0 . This dependency appears to be originate from a corresponding dependency in the upstream setup.py file.
Under Debian version comparison rules (which may differ from upstream python ones, i'm not sure) 3.0-1 << 3.0.0, so
python-cryptography 3.0-1 was able to migrate to testing, but 3.1-1 is being blocked.
I filed a bug about this in Debian and received the following reply from Tristan Seligmann
(the maintainer of the Debian python-cryptography package).
I think the upper bound is just bogus and should be removed. Upstream
seems to have added it under the assumption that cryptography follows
semver, but it does not: 2.9 to 3.0 offers the same compatibility
guarantees as 2.8 to 2.9.
Please consider allowing newer versions of "cryptography"
thanks for reporting. hi @fengzhou-msft can we upgrade the cryptography pacakge?
@bim-msft can you help evaluate the impact to key vault if we bump up cryptography to 3.0+ ?
@fengzhou-msft Sure will do. Please do not bump up the version for now.
this causes pip-compile to fail without pyopenssl<20.0.0:
$ pip-compile <(echo azure-cli)
Could not find a version that matches cryptography<3.0.0,>=1.1.0,>=1.3.4,>=2.1.4,>=2.3.1,>=2.5,>=3.2 (from azure-cli==2.16.0->-r /proc/self/fd/17 (line 1))
Tried: 0.1, 0.2, 0.2.1, 0.2.2, 0.3, 0.4, 0.5, 0.5.1, 0.5.2, 0.5.3, 0.5.4, 0.6, 0.6.1, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2, 0.9, 0.9.1, 0.9.2, 0.9.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.1.1, 1.1.2, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.4, 1.5, 1.5.1, 1.5.2, 1.5.3, 1.6, 1.7, 1.7.1, 1.7.2, 1.8, 1.8.1, 1.8.2, 1.9, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.2, 2.2, 2.2.1, 2.2.1, 2.2.2, 2.2.2, 2.3, 2.3, 2.3.1, 2.3.1, 2.4, 2.4.1, 2.4.1, 2.4.2, 2.4.2, 2.5, 2.5, 2.6, 2.6.1, 2.6.1, 2.7, 2.7, 2.8, 2.8, 2.8, 2.9, 2.9, 2.9, 2.9.1, 2.9.1, 2.9.1, 2.9.2, 2.9.2, 2.9.2, 3.0, 3.0, 3.0, 3.1, 3.1, 3.1, 3.1.1, 3.1.1, 3.1.1, 3.2, 3.2, 3.2, 3.2.1, 3.2.1, 3.2.1, 3.3, 3.3, 3.3, 3.3.1, 3.3.1, 3.3.1
There are incompatible versions in the resolved dependencies:
cryptography (from azure-multiapi-storage==0.5.2->azure-cli==2.16.0->-r /proc/self/fd/17 (line 1))
cryptography>=2.1.4 (from azure-keyvault==1.1.0->azure-cli==2.16.0->-r /proc/self/fd/17 (line 1))
cryptography>=1.1.0 (from adal==1.2.5->azure-cli-core==2.16.0->azure-cli==2.16.0->-r /proc/self/fd/17 (line 1))
cryptography<3.0.0,>=2.3.1 (from azure-cli==2.16.0->-r /proc/self/fd/17 (line 1))
cryptography>=3.2 (from pyOpenSSL==20.0.1->azure-cli-core==2.16.0->azure-cli==2.16.0->-r /proc/self/fd/17 (line 1))
cryptography>=1.3.4 (from urllib3[secure]==1.26.2->azure-cli==2.16.0->-r /proc/self/fd/17 (line 1))
cryptography>=2.5 (from paramiko==2.7.2->scp==0.13.3->azure-cli==2.16.0->-r /proc/self/fd/17 (line 1))
cryptography (from azure-storage-common==1.4.2->azure-cli==2.16.0->-r /proc/self/fd/17 (line 1))
Most helpful comment
this causes pip-compile to fail without
pyopenssl<20.0.0: