Potential dependency conflicts between oraclebmc and cryptography

[NeolithEra]

Hi, as shown in the following full dependency graph of oci, oci requires cryptography ==2.8, oci requires pyopenssl >=17.5.0 (pyopenssl 19.1.0 will be installed, i.e., the newest version satisfying the version constraint), and directed dependency pyopenssl 19.1.0 transitively introduces cryptography >=2.8.

Obviously, there are multiple version constraints set for cryptography in this project. However, according to pip's “first found wins” installation strategy, cryptography 2.8 (i.e., the newest version satisfying constraint ==2.8) is the actually installed version.

Although the first found package version cryptography 2.8 just satisfies the later dependency constraint （cryptography ==2.8), such installed version is very close to the upper bound of the version constraint of cryptography specified by pyopenssl 19.1.0.

Once pyopenssl upgrades，its newest version will be installed, as oci does not specify the upper bound of version constraint for pyopenssl. Therefore, it will easily cause a dependency conflict (build failure), if the upgraded pyopenssl version introduces a higher version of cryptography, violating its another version constraint ==2.8.

According to the release history of pyopenssl, it habitually upgrates Cryptography in its recent releases. For instance, pyopenssl 19.0.0 upgrated Cryptography’s constraint from >=2.2.1 to >=2.3,and pyopenssl 19.1.0 upgrated Cryptography’s constraint from >=2.3 to >=2.8.

As such, it is a warm warning of a potential dependency conflict issue for oci.

Dependency tree

oci - 2.14.2
| +- certifi(install version:2020.4.5.1 version range:*)
| +- configparser(install version:3.5.0 version range:==4.0.2)
| +- cryptography(install version:2.8 version range:==2.8)
| | +- asn1crypto(install version:1.3.0 version range:>=0.21.0)
| | +- idna(install version:2.9 version range:>=2.1)
| | +- six(install version:1.11.0 version range:>=1.4.1)
| +- pyopenssl(install version:19.1.0 version range:>=17.5.0)
| | +- cryptography(install version:2.8 version range:>=2.8)
| | | +- asn1crypto(install version:1.3.0 version range:>=0.21.0)
| | | +- idna(install version:2.9 version range:>=2.1)
| | | +- six(install version:1.11.0 version range:>=1.4.1)
| | +- six(install version:1.11.0 version range:>=1.5.2)
| +- python-dateutil(install version:2.5.3 version range:>=2.5.3,<3.0.0)
| | +- six(install version:1.11.0 version range:*)
| | +- six(install version:1.11.0 version range:>=1.5)
| +- pytz(install version:2016.10 version range:>=2016.10)

Thanks for your help.
Best,
Neolith

[NeolithEra]

Suggested Solution

1. Loosen the version range of cryptography to be >=2.8.
2. Remove your direct dependency cryptography, and use the cryptography transitively introduced by pyopenssl.
3. Change your direct dependency pyopenssl to be >=17.5.0,<=19.1.0.
   @dshelbyo Which solution do you prefer, 1 ,2or 3?
   Please let me know your choice. May I pull a request to solve this issue?

[bhagwatvyas]

Hi @NeolithEra, thanks for bringing this potential dependency issue to our attention. The reason that the cryptography dependency is set to v2.8 is we have tested with, and have compliance and security approval to use v2.8.

While we are reviewing our options regarding updating cryptography, I believe the safest way is to go with option 3 to solve the immediate problem. I would be happy to review your Pull Request.

[bhagwatvyas]

Hi @NeolithEra, I see that you made a commit regarding this to your fork. Pinging you to open a pull request as well :)

[bhagwatvyas]

Hi @NeolithEra, ping again :)

[zedabeta]

I don't want to poach, but would it be alright if I opened this pull request?

[bhagwatvyas]

Hi @zedabeta, we're shipping these changes with the next release tomorrow.

[zedabeta]

Awesome, thanks for letting me know

[bhagwatvyas]

Closing this issue as this is fixed in v2.20.0. Thanks @NeolithEra and @zedabeta for your help!