Vulnerability in setuptools versions up to 69.1.1

[gruzewski]

Describe the bug
Recently, there was a new vulnerability reported against setuptools that could allow RCE, see reports below:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-6345
• https://ubuntu.com/security/CVE-2024-6345

The fix was deployed in version 70.0.0.

Pants version
2.21

OS
Linux

Additional info
From browsing the code, looks Pants is using 63.x.

class Setuptools(PythonToolRequirementsBase):
    options_scope = "setuptools"
    help_short = "Python setuptools, used to package `python_distribution` targets."

    default_requirements = ["setuptools>=63.1.0,<64.0", "wheel>=0.35.1,<0.38"]

    default_lockfile_resource = ("pants.backend.python.subsystems", "setuptools.lock")

[gruzewski]

If the fix is to update that file and regenerating the lock file, I might be able to do that :)

[benjyw]

If the fix is to update that file and regenerating the lock file, I might be able to do that :)

That is the fix, if you can that would be awesome! But note that this is not a normal lockfile in the pants repo, but a resource, that is generated by running pants run build-support/bin/generate_builtin_lockfiles.py setuptools

[benjyw]

I guess the other part of the fix is communication. The code change you've kindly suggested will fix for the next Pants release, but we want to blast out to people how to fix in existing Pants versions, which is basically this:

https://www.pantsbuild.org/2.20/docs/python/overview/lockfiles#lockfiles-for-tools

[benjyw]

I.e., we should strongly recommend that folks upgrade and spell out exactly how to do so. If you're comfortable writing that up @gruzewski?

[krishnan-chandra]

Changing the default version of setuptools to >= 70 may require dropping support for Python 3.7, since later versions of setuptools have dropped support for it as well:

ERROR: Ignored the following versions that require a different python version: 68.1.0 Requires-Python >=3.8; 68.1.2 Requires-Python >=3.8; 68.2.0 Requires-Python >=3.8; 68.2.1 Requires-Python >=3.8; 68.2.2 Requires-Python >=3.8; 69.0.0 Requires-Python >=3.8; 69.0.1 Requires-Python >=3.8; 69.0.2 Requires-Python >=3.8; 69.0.3 Requires-Python >=3.8; 69.1.0 Requires-Python >=3.8; 69.1.1 Requires-Python >=3.8; 69.2.0 Requires-Python >=3.8; 69.3 Requires-Python >=3.8; 69.3.0 Requires-Python >=3.8; 69.3.1 Requires-Python >=3.8; 69.4 Requires-Python >=3.8; 69.4.0 Requires-Python >=3.8; 69.4.1 Requires-Python >=3.8; 69.4.2 Requires-Python >=3.8; 69.5.0 Requires-Python >=3.8; 69.5.1 Requires-Python >=3.8; 70.0.0 Requires-Python >=3.8; 70.1.0 Requires-Python >=3.8; 70.1.1 Requires-Python >=3.8; 70.2.0 Requires-Python >=3.8; 70.3.0 Requires-Python >=3.8; 71.0.0 Requires-Python >=3.8; 71.0.1 Requires-Python >=3.8; 71.0.2 Requires-Python >=3.8; 71.0.3 Requires-Python >=3.8; 71.0.4 Requires-Python >=3.8

Related issue: #21103

[gruzewski]

@krishnan-chandra is right. I got this error:

ERROR: Ignored the following versions that require a different python version: 68.1.0 Requires-Python >=3.8; 68.1.2 Requires-Python >=3.8; 68.2.0 Requires-Python >=3.8; 68.2.1 Requires-Python >=3.8; 68.2.2 Requires-Python >=3.8; 69.0.0 Requires-Python >=3.8; 69.0.1 Requires-Python >=3.8; 69.0.2 Requires-Python >=3.8; 69.0.3 Requires-Python >=3.8; 69.1.0 Requires-Python >=3.8; 69.1.1 Requires-Python >=3.8; 69.2.0 Requires-Python >=3.8; 69.3 Requires-Python >=3.8; 69.3.0 Requires-Python >=3.8; 69.3.1 Requires-Python >=3.8; 69.4 Requires-Python >=3.8; 69.4.0 Requires-Python >=3.8; 69.4.1 Requires-Python >=3.8; 69.4.2 Requires-Python >=3.8; 69.5.0 Requires-Python >=3.8; 69.5.1 Requires-Python >=3.8; 70.0.0 Requires-Python >=3.8; 70.1.0 Requires-Python >=3.8; 70.1.1 Requires-Python >=3.8; 70.2.0 Requires-Python >=3.8; 70.3.0 Requires-Python >=3.8; 71.0.0 Requires-Python >=3.8; 71.0.1 Requires-Python >=3.8; 71.0.2 Requires-Python >=3.8; 71.0.3 Requires-Python >=3.8; 71.0.4 Requires-Python >=3.8; 71.1.0 Requires-Python >=3.8

To get it working, I had to update default_interpreter_constraints in python_tool_base.py.

@benjyw I can look into dropping support for Python 3.7. WDYT?

Updated typo.

[benjyw]

Ooooof. No good deed goes unpunished, huh...

[benjyw]

This would mean dropping support for 3.7 in the default settings. We would still want to support it, and must test for that support, if you're willing to downgrade to a vulnerable setuptools. That seems non-controversial given how old 3.7 is now.

So this would require a new test that uses a downgraded setuptools.

[gruzewski]

So to clarify, I would:

• update the default_interpreter_constraints only in python_tool_base.py
• create a test case for the downgraded setuptools*
• potentially mention on Enabling Python Support that by default only Python >= 3.8 is supported with a link to instructions on how to change it (I am thinking of Lockfiles for tools)

* For the test case, what kind of functionality I should cover? I am thinking of covering similar functionality as in test_plugin_resolver.py, so create a Pex and run a setup.py. Alternatively, checking DistBuildRequest.

[benjyw]

Well, you can override default_interpreter_constraints in just setuptools.py, that's the only thing actually affected. Normally we'd want a deprecation cycle, where we warn you if you're relying on the 3.7 default, but still let you do so. But since this is in response to a CVE I think we can consider dispensing with that. Let's have a quick thread to discuss that on #development channel in Slack?