You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Vulnerability in Python 3.10 (setuptools inside ensurepip folder) #901
We are working on Python 3.10 and found vulnerable version of setuptools package which is setuptools-65.5.0.
We did see Python 3.10 already has a fix for setuptools package and updated version of setuptools package which is setuptools-65.5.1. Though while doing analysis, we found the traces of vulnerable version inside ensurepip folder.
Please refer absolute file paths highlighted by blue in attached screenshot :
I'm sure there's a way -- the best one would be for Python upstream to do new releases with the updated setuptools bundled (because this really isn't a Docker-specific problem -- it just looks like one because we seem to be one of the few parties publishing builds of their sources fairly "vanilla"). I don't know what the likelihood of that happening is, though.
For your builds, it would probably be pretty reasonable to purge the ensurepip module completely from your derivative images, but I must admit I don't know how common ensurepip is for users to actually use.
For your builds, it would probably be pretty reasonable to purge the ensurepip module completely from your derivative images, but I must admit I don't know how common ensurepip is for users to actually use.
Removing ensurepip could break the ability to bootstrap pip into new virtual environments created with venv (a tool for creating isolated Python environments), or other systems that rely on ensurepip to ensure pip is available. Hence, I don't think we should remove ensurepip from our images.
it just looks like one because we seem to be one of the few parties publishing builds of their sources fairly "vanilla"
@tianon Is the python image always build with latest builds of Python?
I think this issue should be closed as wontfix, given that the fix should come from upstream (as the wheel in the ensurepip folder comes from upstream).
Activity
samruddhikhandale commentedon Jan 19, 2024
As
ensurepipmodule is part ofpip, does the Python image needs an update for thepippackage as well?We use the python image as base for the dev container images which are getting flagged with the
setuptoolsvulnerability in our scanners.We appreciate the quick fix for #783, hoping to get this resolved as well. Thank you!
// cc @tianon
tianon commentedon Jan 19, 2024
The
ensurepipmodule is part of Python's own stdlib (which is thus where this is coming from), notpip😭samruddhikhandale commentedon Jan 19, 2024
Hmmm. @tianon Is there any way to patch this? 🤔
tianon commentedon Jan 19, 2024
I'm sure there's a way -- the best one would be for Python upstream to do new releases with the updated
setuptoolsbundled (because this really isn't a Docker-specific problem -- it just looks like one because we seem to be one of the few parties publishing builds of their sources fairly "vanilla"). I don't know what the likelihood of that happening is, though.For your builds, it would probably be pretty reasonable to purge the
ensurepipmodule completely from your derivative images, but I must admit I don't know how commonensurepipis for users to actually use.samruddhikhandale commentedon Jan 19, 2024
Removing
ensurepipcould break the ability to bootstrappipinto new virtual environments created withvenv(a tool for creating isolated Python environments), or other systems that rely onensurepipto ensurepipis available. Hence, I don't think we should removeensurepipfrom our images.@tianon Is the python image always build with latest builds of Python?
@bhupendra-vaishnav can you raise this issue in https://github.com/python/cpython and request them to update their
ensurepipbundle?tianon commentedon Jan 19, 2024
Yep, we build from the latest published releases and try to keep any changes minimal.
See https://github.com/docker-library/python/blob/b273afc57978521d33fefe5887ad901d0d35de87/3.10/bookworm/Dockerfile for the current
Dockerfileforpython:3.10.edmorley commentedon Aug 24, 2024
I think this issue should be closed as wontfix, given that the fix should come from upstream (as the wheel in the ensurepip folder comes from upstream).