snyk test produces an issue for setuptools==68.0.0 with high severity in the output when run in a 3.12 venv when setuptools is in the dependency list

[RollerKnobster]

• node -v: v18.5.0
• npm -v:
• snyk -v: 1.1292.1
• Command run: snyk test --file=requirements.txt

In our case, we install tensorflow as a dependency, which has setuptools==70.0.0 in its list of dependencies. Upon running snyk test, setuptools==68.0.0 is installed, which results in the output of snyk test containing an issue related to the high vulnerability in setuptools==68.0.0.

As per my uneducated and honestly haphazard look at the code, ideally, if setuptools is already present in the environment, the setuptools installation step should be skipped. At the very least, bumping UPDATED_SETUPTOOLS_VERSION to 70.0.0 is desirable. I'm not sure if excluding setuptools from the list of dependencies to scan is easily achievable.

I presume this can be handled via a Policy, but I would like to not to have to do it manually.

Expected behaviour

When setuptools>68.0.0 is specified in the requirements either explicitly or transiently, and is present in the venv, upon running snyk test, no vulnerabilities related to setuptools are expected in the output, and ideally, setuptools shouldn't be re-installed back to 68.0.0.

Actual behaviour

When setuptools>68.0.0 is specified in the requirements either explicitly or transiently, and is present in the venv, upon running snyk test, a vulnerable 68.0.0 version is installed, and an issue for it is displayed in the output.

Steps to reproduce

1. Create a new Python 3.12 venv and activate it.
2. Create a requirements.txt file with either setuptools==70.0.0 specified directly, or with tensorflow==2.16.2 specified.
3. Install the dependencies via pip install -r requirements.txt.
4. Run snyk test --file requirements.txt
5. The output will include an issue for setuptools==68.0.0 with high severity, and pip list | grep setuptools will return setuptools 68.0.0.

[jmahlik]

I agree pinning the setuptools version in the plugin is asking for trouble. But setuptools does make breaking changes quite often.

Is tensorflow or something else in your stack declaring a runtime dependency on setuptools so it's showing in the requirements? It should only be a build time dependency in an ideal world.

I ended up going through our dep tree and submitting PR's to all the projects to remove setuptools' runtime dependency if it wasn't needed. Not a great solution but that's how I ended up solving setuptools being in the scan.

-- edit

Ended up finding a project that does have a runtime dependency on setuptools. This indeed does cause the issue you describe.

[jmahlik]

Maybe the plugin could vendor setuptools?

[RollerKnobster]

Is tensorflow or something else in your stack declaring a runtime dependency on setuptools so it's showing in the requirements? It should only be a build time dependency in an ideal world.

Indeed, both TensorFlow and TensorBoard declare them in their final full dependency list, which doesn't immediately make sense to me since I can not find any usage of it outside package building. I would absolutely want them to separate build and runtime dependencies, but upon further search, other libraries do include setuptools also, with various reasoning as to why.

I agree that the most beneficial approach overall would be to nudge them to remove setuptools from runtime dependencies, but I still have trouble convincing myself that having a third-party tool implicitly meddling with the environment is acceptable (for various reasons, like minor inconveniences of having my local env changed and having to re-install dependencies after running snyk, or having possible implications for CI/CD pipelines people can extend with snyk checks on various steps and potentially prior to building).

Your argument on breaking changes is very valid, and considering that, it will probably be fairly unreasonable to support arbitrary versions that could already be present in an environment. I would love for it, at the end of the day, to be handled in the plugin, and to not have to do preps and cleanups and adding ignores on my side for this.

I believe vendoring can be an acceptable approach, although I don't have any other ideas at the moment.

[RollerKnobster]

This has been seemingly resolved by #246