-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
Given that we're pinned to the specific version of |
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. |
Found a workaround in the meantime, @luca-dela. Added this as the first line after the
|
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? |
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 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 |
I would imagine this would be the same for the version of pip being used? |
I'm not sure what you're asking - whether our policy for not updating |
Thank you, that was what I was asking. |
Given that the currently bundled version of setuptools (65.5.0) is vulnerable to this vulnerability, it would be good to bump that up.
The text was updated successfully, but these errors were encountered: