Version pinning

[datamuc]

Is your feature request related to a problem? Please describe.

https://github.com/vmware/vsphere-automation-sdk-python/blob/master/requirements.txt#L6-L9

Is this strict pinning really necessary?

Describe the solution you'd like

replace == with >=

Describe alternatives you've considered

No response

Additional context

No response

[aagrawal3]

Hi @datamuc, We have pinned the dependencies to a version which we know works. We plan to keep pinned versions to avoid any unwanted/unforeseen issues.

[MallocArray]

@aagrawal3 This does cause issues when building an Ansible Execution Environment that runs multiple Ansible Collections as each collection can have their own pinned version that we can't satisfy.

And even more concerning when the pinned versions are quite a bit older, such as cryptography pinned at 36.0.0 when 39.0.2 is out

[aagrawal3]

We acknowledge this and will be removing pinned versions in our upcoming release.

[sodul]

@aagrawal3 would it be possible to get fix releases in between the major releases. Often times bug fixes are only released alongside major changes that might not be backward compatible and waiting several months to address dependency conflicts is causing headaches to the users of the SDK.

[aagrawal3]

Hi @sodul Thank you for your valuable input. We address security vulnerabilities and major bugs (blockers) in SDK patch releases. For this particular issue, we are very close to our 8.0U1 (Update release over 8.0) release and hence decided to address it within the scope of this release.

[MallocArray]

Is there an ETA on the 8.0U1 release? The version pinning of cryptography and setuptools means we are vulnerable to 2 different high CVEs that can be resolved with later versions setuptools https://avd.aquasec.com/nvd/2022/cve-2022-40897/

cryptography https://avd.aquasec.com/nvd/2023/cve-2023-23931/ https://avd.aquasec.com/nvd/2023/cve-2023-0286/

[aagrawal3]

Release will be completed before end of April.

[sodul]

@MallocArray our workaround has been to install the vsphere sdk first, let it pull whatever it wants, then install our own requirements and ignore the vsphere sdk dependencies. Our entire dependency tree is then very fresh with all CVEs properly addressed. It does mean that we have a shell script to orchestrate what a single requirement.txt should be able to do. Thankfully this approach works well and we have not encountered any compatibility issue but you might be using other parts of the sdk that could be incompatible.

[aagrawal3]

Addressed in https://github.com/vmware/vsphere-automation-sdk-python/pull/372