Repository navigation
Update setuptools version following CVE-2022-40897 #781
Description
Given that the currently bundled version of setuptools (65.5.0) is vulnerable to this vulnerability, it would be good to bump that up.
Given that the currently bundled version of setuptools (65.5.0) is vulnerable to this vulnerability, it would be good to bump that up.
Activity
tianon commentedon Dec 29, 2022
Given that we're pinned to the specific version of
setuptoolsthat comes bundled with each Python release, shouldn't they be doing new releases to pick up the fixed versions ofsetuptoolsas well?Quinncuatro commentedon Jan 5, 2023
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 commentedon Jan 5, 2023
Found a workaround in the meantime, @luca-dela.
Added this as the first line after the
FROMin myDockerfile:Quinncuatro commentedon Jan 5, 2023
#365 (comment)
Looks like we're back to here:
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 commentedon Jan 5, 2023
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).
Looking at the current spread of
setuptoolsversions, 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 updatesetuptoolsin 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 ofsetuptoolsthat 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
setuptoolsentirely from production containers, but that's a whole different discussion.)coltonfreeman26 commentedon Mar 16, 2023
I would imagine this would be the same for the version of pip being used?
tianon commentedon Mar 16, 2023
I'm not sure what you're asking - whether our policy for not updating
pipversions is the same assetuptools? (that's a resounding "yes" - we pin to the version ofpipthat each version of Python includes, for compatibility's sake)coltonfreeman26 commentedon Mar 27, 2023
Thank you, that was what I was asking.