GeezerVison is showing github.com — Update bundled setuptools provided by ensurepip in current 3.8.x through 3.11.x to include fix for CVE-2022-40897? · Issue #102202 · python/cpython
Update bundled setuptools provided by ensurepip in current 3.8.x through 3.11.x to include fix for CVE-2022-40897? #102202Activityhugovk commented on Feb 24, 2023 ned-deily commented on Feb 26, 2023 Regarding backporting to 3.7, see my comment on the PR. In short, I don't want to backport this to 3.7 as the benefits are minimal and the risks are high. Reacted by Hugo van Kemenade LianwMS commented on Feb 27, 2023 ned-deily commented on Feb 27, 2023
So, the security should be fixed in 3.10-3.12. Correct?
Ultimately, it's up to the release managers for those releases but I expect they will be updated soon.
However, your original question seems to be about an Alpine docker image with python3.9. If so, you should check with the maintainer of that image. It should be a trivial matter to update the image with the new version of setuptools. Or you can just update it yourself when running the image by using some variant of:
python3.9 -m pip install --upgrade pip
python3.9 -m pip install --upgrade setuptools
A CPython update to ensurepip by itself isn't going to make a difference to the Docker image. Reacted by Mohammad Mesbah hugovk commented on Apr 27, 2023 Also not needed for 3.12, setuptools was removed in #101039. ned-deily commented on Dec 7, 2023 To follow up on this, the current status is that we are still shipping various older versions of setuptools with ensurepip in Python 3.11 and 3.10 (65.5.0), 3.9 (58.1.0), and 3.8 (56.0.0). (We no longer include setuptools with ensurepip as of 3.12.) It should be up to the affected release managers to decide what action, if any, should be taken and then update and close this issue. Are there other potentially relevant security fixes in setuptools?
cc: @pablogsal @ambv @sethmlarson changed the title [-][3.9] Any plan about fixing CVE-2022-40897 in python 3.9-alpine[/-] [+]Update bundled setuptools provided by ensurepip in current 3.8.x through 3.11.x to include fix for CVE-2022-40897?[/+] on Dec 7, 2023sethmlarson commented on Dec 7, 2023 @ned-deily Beyond CVE-2022-40897 there aren't any additional vulnerabilities in setuptools. I don't think it's particularly bundersome to ask users to upgrade pip when using ensurepip to bootstrap, pip itself will start issuing warnings about being out of date as well.
In fact, could we make ensurepip automatically attempt to upgrade the installed pip during bootstrapping (ie set --upgrade to True by default?)? cc @pradyunsg ned-deily commented on Dec 7, 2023
In fact, could we make ensurepip automatically attempt to upgrade the installed pip during bootstrapping (ie set --upgrade to True by default?)? cc @pradyunsg
We could but that approach was rejected in the original PEP proposing ensurepip. That could be revisited. ned-deily commented on Jan 23, 2024 Mark as release blocker for 3.8, 3.9, and 3.10 decisions. bhupendra-vaishnav commented on Jan 24, 2024 @ned-deily Is there any tentative release date for the vulnerability fix? This issue came to us from our customer as high-priority issue. samruddhikhandale commented on Feb 2, 2024 Looking for some updates on this vulnerability patching, thanks! encukou commented on Feb 6, 2024 So, a DoS can be caused by a package that's considered for download and installation (which can run arbitrary code), or by the site that serves such packages?
I don't see how this can be exploited without the attacker being able to do much more damage; a fix will mainly silence automated checkers.
@sethmlarson, you have more info; let me know (possibly privately) if we need to fix this somehow.
Unfortunately, setuptools had breaking changes since 58.1 (and 65.5).
Back in my old job, I'd do a surgical patch to fix the regex only. Not sure if that's appropriate for CPython, but if we're distributing a library that's no longer supported upstream, it probably should be. sethmlarson commented on Feb 6, 2024 @encukou I agree that there isn't much benefit to patching that CVE and it's only likely to cause breakages.
@samruddhikhandale @bhupendra-vaishnav As far as finding a solution to your issue, it seems that scanners are alerting regardless of whether that file is completely inert and useless in the image. Maybe a way forward is to ensure pip and setuptools are bootstrapped to versions that you're happy with (ie python -m pip install --disable-version-check pip==... --hash=...; python -m pip install setuptools==... --hash=...) and then the Lib/ensurepip/_bundled/... directory can be deleted entirely? samruddhikhandale commented on Feb 6, 2024
Lib/ensurepip/_bundled/... directory can be deleted entirely?
We tried deleting the directory, but then pip fails to work 😓 Hence, we are not able to patch it on our end.
Maybe a way forward is to ensure pip and setuptools are bootstrapped to versions that you're happy with
Yep, we already have that logic added, thanks! pradyunsg commented on Feb 6, 2024
the Lib/ensurepip/_bundled/... directory can be deleted entirely?
IIUC, this will break ensurepip, which breaks venv since venv relies on ensurepip to install a copy of pip (and setuptools) in the environment. Reacted by Samruddhi Khandale encukou commented on Feb 9, 2024 Note that you can run venv with --no-pip, and then install pip separately.
If you redistribute Python, you could try to replace the wheels and adjust the version numbers in Lib/ensurepip/__init__.py. (And test that the incompatibilities in the new versions don't affect you, of course.)
I agree that there isn't much benefit to patching that CVE and it's only likely to cause breakages.
With that, let's close. It's not a notable security vulnerability in Python. Telling that to your security scanner is, in this case, up to you.
@ambv @pablogsal, please tell me if I'm out of line and I should have left this decision to you. Reacted by Pradyun Gedam and Łukasz Langa laptchik commented on Apr 8, 2025
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|