Hi Tom,

Tom <wirelessduck@???> writes:

> On 8 Jul 2024, at 21:43, Olaf Meeuwissen via Dng <dng@???> wrote:
>
>> Hi Lorenz,
>>
>> I saw that Nick's reply already solved your issues but wanted to comment
>> on something not directly related to that.
>>
>>> Lorenz via Dng <dng@???> writes:
>>>
>>> [...]
>>>
>>> I'm using the follwing dockerfile:
>>>
>>> --------------------------------
>>> # dockerfile for runit-services testsuite
>>> #
>>> FROM debian:sid
>>> MAINTAINER plorenzo@???
>>>
>>> RUN apt-get update -q -q && apt-get upgrade --yes
>>
>> Rather that running apt-get upgrade (which is generally advised against
>> IIRC), I would rebuild your runit-testsuite image regularly with --pull.
>> The debian:sid images are updated every three or four weeks by the looks
>> of the Docker Hub tags for sid.
>
> It’s no longer advised to not run apt-get upgrade in Dockerfiles.
>
> https://pythonspeed.com/articles/security-updates-in-docker/
>
> Hadolint and OWASP have removed this advice for a while now.
>
> https://github.com/hadolint/hadolint/issues/562
> https://github.com/OWASP/CheatSheetSeries/pull/614#issuecomment-806209720

Thanks you VERY much for these pointers. I was going to reply earlier
but decided to let the content of the links sink in a bit first.

I'd like to point out that the author of the first post (and submitter
of the referenced issues) assumes that you are using a *stable* release.
I don't think debian:sid qualifies, ;-)

That notwithstanding, the author has a point and actually posted two
related interesting articles creating the following "trilogy":

- https://pythonspeed.com/articles/security-updates-in-docker/
- https://pythonspeed.com/articles/docker-cache-insecure-images/
- https://pythonspeed.com/articles/disabling-docker-caching/

My key take-aways of that are that

- security is a continuous process
- image purpose dictates best practice

For the first one, I'd say you would need to check the container images
you use on a regular basis to see if they need rebuilding. Or never
mind that check and blindly rebuild on the same basis.

I use a daily check for the devuan/devuan images and trigger a rebuild
if there are upgradable packages. That goes a bit like this

  docker pull devuan/devuan:$codename
  n=$(docker run devuan/devuan:$codename \
        sh -c 'apt-get update && \
               apt list --upgradable 2>/dev/null | wc -l')
  if test $n -gt 0; then
    docker build --pull --no-cache .
  fi

The details are a bit more involved but you can see those at

https://git.devuan.org/paddy-hack/container-images

See the disabling-docker-caching article mentioned above for
alternatives to bust the Docker build cache.

For my second takeaway there is only case-by-case advice. If you're
building base images for wide-spread sharing, like the devuan/devuan
ones ;-), or images to deploy services to production, regularly checking
the need to rebuild is the Right Thing to do. In that respect, the
Debian (and Ubuntu) images could do a better job as they seem to be on a
multi-week rebuild schedule with no obvious trigger.

If you are using a base image in the test phase of your CI pipeline,
then there is not much need to make sure that all the latest security
issues are addressed. Moreover, for reproducability purposes in the
case that those CI tests fail, you probably want to control when (and
how!) your images change. Whether you want to use *stable* upstream
images or not is your call.

In Lorenzo's case, testing of the Debian runit-init and runit-services
packages, I would agree that tests need to be run against debian:sid.
An upgrade to his packages would enter the package repositories there.
When using debian:sid, it is rather likely that there are upgradable
packages in the image so I would suggest something like the following
Dockerfile (untested!)

  FROM debian:sid AS runit-init
  RUN dpkg -r --force-remove-protected init
  RUN apt-get update -q -q && \
      apt-get install -y --no-install-recommends runit && \
      apt-get install -y runit-init \
                         libpam-elogind dbus-x11 \
                         opensysusers systemd-standalone-tmpfiles &&\
      rm -rf /var/lib/apt/lists/*
  COPY testsuite-as-a-service/ /tests
  ARG cache_buster
  RUN echo $cache_buster && \
      apt-get update -q -q && \
      apt-get upgrade -y
  ENTRYPOINT ["/sbin/init"]

  FROM runit-init AS runit-services
  RUN apt-get remove -y libnss-systemd && \
      apt-get install -y runit-services getty-run

With the above Dockerfile (re)build images with

  cache_buster=$(date +%F)
  docker build --pull \
               --build-arg cache_buster \
               --target runit-services \
               --tag runit-services-tester:$cache_buster
  docker tag runit-services-tester:{$cache_buster,}
  docker build --build-arg cache_buster \
               --target runit-init \
               --tag runit-init-tester:$cache_buster
  docker tag runit-init-tester:{$cache_buster,}

The idea is that the first build will always use the latest debian:sid
and upgrade all packages at the end. This upgrade happens when a new
debian:sid was pulled and when no builds exist that used the same value
of cache_buster. See

https://docs.docker.com/reference/dockerfile/#impact-on-build-caching

for details on how ARG values impact build caching.

The second build should be able to reuse everything it needs from the
results that were cached during the first.

The `docker tag` invocations are there so that you can refer to the
images without the $cache_buster tag in your CI pipeline. If tests
fail, you can use the $cache_buster tag for debugging purposes.

Hope this helps,
--
Olaf Meeuwissen