Install python packages through pip, not system manager

[brsolomon-deloitte]

This changes installation of wheel, setuptools, and pip to be conducted through pip rather than using the OS package manager python3-xxx versions. The package manager versions are outdated and subject to unpatched security vulnerabilities.

[coolacid]

Thanks for the PR, The main problem I have with this is the running of unsigned code from the internet for system level applications.

Yes, this is one recommended way to install pip, however it's generally frowned upon for production systems as there is no enforcement of validation, where the system packages do.

Of course, one could easily say the same thing about any python code, however, hopefully most of the time those aren't run as root.

[brsolomon-deloitte]

This is the way that the official python image does it. (They do validate the shasum, but checksum validation is admittedly different from verifying signature.)

An alternative would be to apt-get install python3-pip and then pip3 --upgrade pip, would that be preferable?

[coolacid]

Yes, and the onus is now on official python team to ensure the efficacy of their image. By using the package maintainers version for root level packages, the onus is on the package maintainers.

By pulling this in at this level, the onus is on me to say I'm certain what is built is what is from upstream.

Can you point me at the CVEs related to the outdated tools, or the pages from debian as to why they haven't patched their versions?

Alternatively, research could be done to see if the packages are required after the build and just removed from the created image.

[brsolomon-deloitte]

Can you point me at the CVEs related to the outdated tools, or the pages from debian as to why they haven't patched their versions?

• wheel: https://nvd.nist.gov/vuln/detail/CVE-2022-40898; pypa/wheel@88f02bc
• pip: index-url extra-index-url install priority order pypa/pip#8606

A separate suggestion: what if, for the python-build layer, you use a python (debian/slim bullseye) image as the base image rather than starting with slim bullseye and installing python on it from the OS package manager?

---

Update: I realize these changes in the python-build layer would matter very little since only /wheel is copied into the final image.

[coolacid]

• wheel: https://nvd.nist.gov/vuln/detail/CVE-2022-40898; pypa/wheel@88f02bc

Regarding the Wheel issue, the dev's claim it to be a non-viable attack vector. Additionally, it would only be an issue during the invocation of the cli command. If someone was able to get into the docker container, a multitude of scenarios already exist to DoS the service which are much easier then targeting wheel.

• pip: index-url extra-index-url install priority order pypa/pip#8606

It's not classified as a vulnerability, it's also targeting using the index-urls, neither of which is used to build these images.

A separate suggestion: what if, for the python-build layer, you use a python (debian/slim bullseye) image as the base image rather than starting with slim bullseye and installing python on it from the OS package manager?

I was actually just going to suggest this.

I think two better approaches would be to use the official python image for the python build, and investigate if they could be removed at the end of the build process.

[brsolomon-deloitte]

Thanks for being receptive to changes.

the dev's claim it to be a non-viable attack vector

Understood; it's very possibly a false positive. But from the perspective of the image user (me) who has to answer to a security team and meticulously document why certain flagged vulnerabilities are in fact false positives, it makes life easier if the upstream image makes reasonable measures to remove those vulnerabilities in the first place :)

[coolacid]

Understood; it's very possibly a false positive. But from the perspective of the image user (me) who has to answer to a security team and meticulously document why certain flagged vulnerabilities are in fact false positives, it makes life easier if the upstream image makes reasonable measures to remove those vulnerabilities in the first place :)

Yep, been on both sides of that fence, both responsible for production and evaluation of said reports. Hence why I don't blindly accept changes without looking at the whole scope of change. Also why I defer upstream where ever possible since they should have the people power to track and mange those items.

For documentation, here's Debian's take on:

wheel issue: https://security-tracker.debian.org/tracker/CVE-2022-40897 -- They mark it as no dsa meaning basically ignored for buster -- https://security-team.debian.org/security_tracker.html#issues-not-warranting-a-security-advisory

pip issue: https://security-tracker.debian.org/tracker/CVE-2018-20225 -- They do mark this as vulnerable, but marked disputed and unimportant.