Update bundled setuptools provided by ensurepip in current 3.8.x through 3.11.x to include fix for CVE-2022-40897?

[LianwMS]

Just found the image are impacted. Any fix plan?
GHSA-r9hx-vwmv-q579

Linked PRs

• gh-102202: Update bundled setuptools to 67.4.0 #102208

[hugovk]

CVE-2022-40897 is a ReDoS in setuptools, fixed in setuptools 65.5.1 (released Nov 4, 2022):

• https://setuptools.pypa.io/en/latest/history.html#v65-5-1

The 3.9 branch has setuptools-58.1.0-py3-none-any.whl (Sep 22, 2021):

• https://github.com/python/cpython/tree/3.9/Lib/ensurepip/_bundled

The main branch has setuptools-65.5.0-py3-none-any.whl (Oct 14, 2022):

• https://github.com/python/cpython/tree/main/Lib/ensurepip/_bundled

---

Before updating, Python 3.7-3.9 are security-fix only (https://devguide.python.org/versions/), let's first check with release managers @ambv and @ned-deily.

A quick check shows the CI passes for 3.9: https://github.com/hugovk/cpython/actions/runs/4260373632

[ned-deily]

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.

[LianwMS]

@hugovk @ned-deily So, the security should be fixed in 3.10-3.12. Correct?

[ned-deily]

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.

[hugovk]

Also not needed for 3.12, setuptools was removed in #101039.

[ned-deily]

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

[sethmlarson]

@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]

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]

Mark as release blocker for 3.8, 3.9, and 3.10 decisions.

[bhupendra-vaishnav]

@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]

Looking for some updates on this vulnerability patching, thanks!

[encukou]

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]

@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]

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]

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.

[encukou]

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.