Vulnerabilities related to stdlib 1.19 and setuptools 44.1.1

[chka01]

Container image name

rocker/rstudio:latest

Container image digest

rocker/rstudio@sha256:e6559b33f732059bd07706fe20e425677e01a765c4881af7bdbe7c123035e79c

What operating system related to this question?

No response

System information

No response

Question

I have searched the latest image available on docker hub (rocker/rstudio:latest) and it seems to have some security vulnrabilities genereated in the layer associated with the command /bin/sh -c /rocker_scripts/install_rstudio.sh # buildkit.
Main once with critical and high vulnrabilities based on output from docker scout are stdlib 1.19 and setuptools 44.1.1.

Is there any way to solve these issues, or any recomendations how to fix/other image i should use?

Thank you in advance.

[eitsupi]

I think these are came from here

rocker-versioned2/scripts/install_rstudio.sh

Line 40 in 56ce3b8

python-setuptools \

I think this can be resolved by automatically resolving dependencies using gdebi-core like this:
https://github.com/rocker-org/devcontainer-features/blob/cd2528c5a4f5a321c144446efa8301c1dec7ed27/src/rstudio-server/install.sh#L151-L167

PR for fix this is welcome!

[cboettig]

@eitsupi I am probably just missing something, but why are we using the apt_install wrapper instead of apt-get install? My understanding is that wrapping with apt_install specifically causes the command to skip installing an updated version if an earlier version is detected(?) Isn't this explicitly preventing the rebuilding from automatically being able to bring in security patches? If the goal is to install only security updates and not others, I believe their are standard debian mechanisms here?

[eitsupi]

I don't think reinstallation will be a problem since the latest base image will be used during the rebuild.
More importantly, note that python-setuptools is specified here, not python3-setuptools.

My guess is that this is an ancient dependency and I have a feeling that Python2 is being installed for no good reason.
https://packages.ubuntu.com/jammy/python-setuptools
https://packages.ubuntu.com/jammy/python3-setuptools

[eitsupi]

why are we using the apt_install wrapper instead of apt-get install?

My motivation is to skip the useless execution of apt-get update in the absence of newly installed packages.
For example, various scripts use wget, but running apt-get update without checking for the existence of wget wastes time by unnecessary running.
This can be a very frustrating overhead, especially in regions far from the Americas, due to communication time issues with the Ubuntu server.

[cboettig]

Thanks @eitsupi ! yes, that sounds right. a quick check builds fine after making this python3-setuptools, though I would have thought even the older version is still under the purview of the Ubuntu security team.

(Aside, but a nice interview at https://podcast.sustainoss.org/203 with the maintainer of cURL on the limitations of the CVE vulnerability database -- the classification of these vulnerabilities is not nearly as careful or precise process as I might have imagined. Anyway, my general take is to defer to security experts on these issues :-). But I'm all for changing this dependency to python3 or switching to gdebi here.

[benz0li]

ℹ️ Regarding CVEs (not) reported for Ubuntu:

For some added insight, the primary reason I've found over the years that CVE scanners are less kind to Debian than they are to Ubuntu is that Ubuntu clearly marks CVEs as "WONTFIX" (which the scanners than interpret as "hide this CVE"), where the Debian Security Team never says outright that something will not be fixed because any Debian Developer / member of the project (or someone with enough time to do the work and find a sponsor for it) can fix any issue they like.

For example, the maintainer of a given package could choose to fix every CVE filed against their packages in stable, if they so chose, even if the Security Team at large has decided that most of them aren't worth fixing in stable. The way the Security Team normally telegraphs their evaluation of the CVE's severity within the context of the Debian package and how it is used is with a "no-dsa" tag in the notes, which IMO all the scanning vendors should pick up and interpret the same as they do "WONTFIX" in Ubuntu (because it really is the exact same meaning), but I have not seen any of them doing so, even in spite of the many long meetings I've had with several of them describing this. 😞

– docker-library/python#708 (comment)

[eddelbuettel]

Debian dev here: No, you don't get it into stable. Everybody can upload to unstable, it may migrate to testing. You need release managers to get it into the releases made.