Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update setuptools version following CVE-2022-40897 #781

Closed
tweirtx opened this issue Dec 28, 2022 · 8 comments · Fixed by #783
Closed

Update setuptools version following CVE-2022-40897 #781

tweirtx opened this issue Dec 28, 2022 · 8 comments · Fixed by #783

Comments

@tweirtx
Copy link

tweirtx commented Dec 28, 2022

Given that the currently bundled version of setuptools (65.5.0) is vulnerable to this vulnerability, it would be good to bump that up.

@tianon
Copy link
Member

tianon commented Dec 29, 2022

Given that we're pinned to the specific version of setuptools that comes bundled with each Python release, shouldn't they be doing new releases to pick up the fixed versions of setuptools as well?

@Quinncuatro
Copy link

Is there a reason this hasn't been addressed yet? This is causing my CI/CD scanner to fail all my builds, since the base layer of my image is generating a high alert.

@Quinncuatro
Copy link

Found a workaround in the meantime, @luca-dela.

Added this as the first line after the FROM in my Dockerfile:

RUN pip install -U setuptools

@Quinncuatro
Copy link

Quinncuatro commented Jan 5, 2023

#365 (comment)

Looks like we're back to here:

In looking into the details of how to implement this, my plan was to pin everything to whatever's the latest minor release of each today, with the plan in the future to be pinning to the minor release track that's included with the associated Python release (for example, if Python 3.11 contains PIP 22.x, we'd pin to that same 22.x for the duration of Python 3.11).

Since this is happening again, is it a good idea to nix that "we'll pin the release that's included with the associated Python release" bit?

@tianon
Copy link
Member

tianon commented Jan 5, 2023

Is there a reason this hasn't been addressed yet?

Yes, we're not going to make this decision and cause breaking changes for users again ourselves (without the consent or recommendation of the Python project) -- we used to do that, and it was painful, so now we follow Python upstream instead (since our goal is to represent them / distribute their tooling faithfully). Someone installing stock Python directly from upstream would have the same version we're embedding, which is ultimately our goal (unless upstream publishes an official recommendation to the contrary, such as an update to their installation documentation suggesting that these versions be updated, which would be a little bit weird).

$ jq -r '.[] | .version + ": " + .setuptools.version' versions.json
3.10.9: 65.5.0
3.11.1: 65.5.0
3.12.0a3: 65.5.0
3.7.16: 57.5.0
3.8.16: 57.5.0
3.9.16: 58.1.0

Looking at the current spread of setuptools versions, I'd only be willing to consider making a minor exception for this and embedding 65.5.1 for 3.10, 3.11, and 3.12-rc (everything else is going to be a much larger breaking change, so if you're using 3.7, 3.8, or 3.9, you'll have no choice but to either update setuptools in your own image or try to make a case upstream for them bumping the versions; that being said, I'm guessing they're going to hesitate for the same breaking-changes reason I am, and the likelihood of getting new 57.x or 58.x releases of setuptools that fix this CVE with minimal other changes is probably low).

In reading the vulnerability details, it seems like the attack vector here is relatively slim? It not only requires actively installing packages, but doing so from a malicious package index, which hopefully isn't PyPI? (If PyPI becomes malicious for some reason, we've probably got some much bigger problems, and I think it's accessed over TLS by default anyhow so hard to MitM; it's also not likely to actually happen in a deployed production container -- honestly it would probably be pretty reasonable to strip setuptools entirely from production containers, but that's a whole different discussion.)

@coltonfreeman26
Copy link

I would imagine this would be the same for the version of pip being used?

@tianon
Copy link
Member

tianon commented Mar 16, 2023

I'm not sure what you're asking - whether our policy for not updating pip versions is the same as setuptools? (that's a resounding "yes" - we pin to the version of pip that each version of Python includes, for compatibility's sake)

@coltonfreeman26
Copy link

Thank you, that was what I was asking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants