setuptools 44.0.0 vendored in PEX triggers CVE-2024-6345

[mict0]

Hi PEX team,

I'm using PEX via a project that depends on it (in this case, Dagster), and a recent security scan flagged a critical issue due to setuptools 44.0.0 being vendored inside PEX:

CVE-2024-6345
https://nvd.nist.gov/vuln/detail/CVE-2024-6345

Path: /pex/vendor/_vendored/setuptools/setuptools-44.0.0+<hash>.dist-info/METADATA

This happens even if we upgrade the system-wide setuptools, since PEX uses its own internal vendored version.

Questions:

1. Is there a newer version of PEX that vendors a secure setuptools (≥ 70.0.0)?
2. If not, could a new release be published with the updated vendored version?
3. Is there any way to override or remove the vendored setuptools in the current build?

Thanks for your work — just hoping to resolve this so we can clear our security scans.

Best,
Milos

[jsirois]

The short of it is that the old setuptools is only used if:

1. You use the default --pip-version instead of some newer --pip-version (see the list below ¹).
2. Your packaged code uses setuptools but does not declare a dependency on setuptools (this generally means you use pkg_resources-style namespace packages and forgot to declare a setuptools dependency.

So the security vulnerability does not actually apply to you as long as you're using --pip-version 24.1 or greater (or --pip-version latest and your Pex is 2.5.0 or newer) in your Pex invocations.

For what its worth, there are also likely many more vulnerabilities in all the old code Pex vendors ². All this code is vendored at the newest possible version that supports our oldest Python 2.7 customers and so it has to stay and it has to stay at those versions since Pex rule 0 is never break existing users. New users just need to use Pex options to select newer --pip-versions or other newer Pex features.

Of your list of three then, only option 3 is a possibility since 1 would break existing customers and 2 would not make sense since only --pip-version vendored (20.3.4), needs setuptools 44. I think realizing option 3 would be a fair bit of work, but it probably could be done at the cost of introducing a fair bit of added complexity to Pex.

Footnotes

1. The Pip versions and the corresponding setuptools and wheel versions:
   https://github.com/pex-tool/pex/blob/2c66932d6645e8e542e5386eae08b9cc2dbb2a21/pex/pip/version.py#L178-L336 ↩

2. Pex vendors alot of very old code, not just setuptools. Here's the roster and the reasons:
   https://github.com/pex-tool/pex/blob/2c66932d6645e8e542e5386eae08b9cc2dbb2a21/pex/vendor/__init__.py#L202-L302 ↩

[jsirois]

See:

• pex 2.1.103 uses pip 20.3.4; pip 20.3.4 has vulnerability CVE-2021-3572 #1877
• Vulnerability CVE-2021-3572 #1528
• Vulnerability CVE-2021-28363 #1527
• Vulnerability CVE-2019-20907 #1526

[gibsondan]

Just chiming in to say that Option 3 described above would be lovely (so that people can have pex installed and use a custom without triggering CVEs from scanners - even if it's harmless in practice, it still tends to raise alarm bells)

[jsirois]

I'm amenable to option 3, but since it's a fair bit of work and I don't have a lot of sympathy for security scan setups that are "dumb" / least effort, I'd like some reciprocal investment in this project. If either of you has channels for this sort of thing I can make it a priority.

[jsirois]

I'll re-open and let #3057 re-close this with the release of Pex 2.77.0 with the caveat, as explained in #2785 (comment) of vendored setuptools only being elided if you are installing Pex for a Python>=3.12 venv. @mict0 hopefully this is a more satisfactory end-point than the prior "trust me, it's unused" explanation. There is now physical proof vendored setuptools is unused in the new published py3.py312-none-any .whl since it is no longer present in the wheel.