Switch base image to Debian Stable

[apyrgio]

Background

Currently, Dangerzone uses Alpine Linux as its base container image. Alpine Linux images have some benefits over traditional OS images (Ubuntu, Debian, Fedora), which are especially appealing to Dangerzone. Those are:

Smaller image footprint

This is important because we bundle our container image in our Windows / macOS installers, and Linux packages. Smaller Dangerzone installers lead to faster download times, or even downloads over metered network. Faster download times are especially important for Tails, in which users download our .deb package over Tor.

Improved security

Alpine Linux always provides the latest version of upstream packages, usually within a few days after a release. This is important for us, because we want to address potential CVEs and software bugs as soon as a release is out. Plus, we get a libc with a smaller attack surface (musl libc), which is nice.

Faster image builds

When testing out new features, it's important for devs to have a fast edit-build-test cycle. Alpine Linux images, due to their lightweight nature and the pretty fast apk package manager, are good candidates.

So, what's the problem then?

What we mentioned above are containers 101, so there's nothing out of the ordinary yet. Here's where it gets more interesting though. All the above benefits of Alpine Linux either do not apply, or are subpar in Dangerzone's case. I want to stres the "Dangerzone's case" part, since what doesn't work for us may work well for other use cases. I'll go through the above benefits again, and explain what's actually going on in our case:

Smaller image footprint

The inner container image currently takes roughly 1.1GiB of space, and consists of 283 packages. A lot of these packages are unnecessary in a container context. Some are graphical utilities, such as mesa-24.2.8-r0, wayland-libs-server-1.23.1-r0, libx11-1.8.10-r0, and bloat our image. Others are multimedia utilities, such as gstreamer-1.24.10-r0, and actually widen our attack surface. This is not theoretical, GStreamer CVEs have been the cause of at least one hotfix release (see security advisory 2024-12-24), and a close call for a second one.

Why are these packages installed in the first place? Because the Dangerzone container image requires LibreOffice, and the Alpine Linux libreoffice-common package depends on libgtk and libgstreamer, which in turn bring the rest of the bloat. To the best of our knowledge, there's no way to install certain packages, while excluding others, or installing a headless LibreOffice variant.

Improved security

Alpine Linux does what it says on the tin: it's on top of new upstream releases, and packages them downstream immediately. But what if the upstream author decides to not release a security fix immediately, or doesn't maintain the project any more? In that case, the security team in Alpine Linux also regularly looks at CVEs for their packages and may even fix the issues themselves (example). The latter requires a lot of effort and diligence for every project that Alpine Linux packages, especially given that it has a much smaller security team than other OSes.

Dangerzone was affected by a CVE slip in November 2023, when we had to rush a hotfix release. Ghostscript was found vulnerable to a critical CVE (CVE-2023-43115), which was published on September 18th. The Ghostscript authors fixed this CVE on their main branch, but decided to not cut a new release. This meant that downstream maintainers had to backport the patches, which happened on mid-October for Debian and Fedora. The Ghostscript authors released a new version on November 1st, which was picked up by Alpine Linux on November 9th. By then, we had just released a container image, and had to issue a hotfix release.

If you also take into account that our attack surface widens in the critical path due to the unnecessary GStreamer dependency, then we are not in a better position security-wise than using an OS like Debian/Ubuntu/Fedora.

Faster image builds

Dangerzone uses PyMuPDF in it's container image, but it's not available on the Alpine Linux repos. This means we have to install it via PyPI. This wouldn't affect build times, if we were building our container image just for amd64 architectures, but we also build an arm64 variant for Apple Silicon CPUs. In that case, we have to build PyMuPDF from source, since there's no musl ARM wheel available in PyPI. This takes quite a lot of time in our developer machines, although we make sure to cache the result via multi-stage builds.

Proposal

Our suggestion to solve the above problems is to switch from Alpine Linux to Debian stable. It seems counter-intuitive due to the documented overhead of the Debian images, but for our particular use case, it beats Alpine Linux in all of the above key areas:

Smaller image footprint

An unoptimized, functionally-equivalent Debian stable image for Dangerzone takes 1GiB, has 293 packages, but no graphical ones or others that widen our attack surface. There are two tricks to achieve that:

• The apt package manager allows to install packages with only the minimum required dependencies, via the -no-install-recommends flag. By installing LibreOffice this way, we can ditch some packages like GStreamer that are not necessary for running LibreOffice.
• Debian offers a headless variant of LibreOffice (libreoffice-nogui) and JRE (default-jre-headless). This way we can ditch the GTK libraries and their dependencies.

As a result, our Debian image is 10% smaller than the Alpine one, without optiizing it further (e.g., removing APT and its deps).

Improved security

The Debian security team has a great track record on keeping on top of CVEs and bug fixes, and posting assessments about them. A security scan of a recently updated Debian image shows several CVEs, but few of them are actionable, and usually ones with severity Low or Negligible. The rest of the CVEs are marked as won't fix, and the Debian security team posts explanations why.

Also, what's very important for us is that the two hotfix releases we mentioned above would not have happened if we were using Debian stable. The GStreamer one would have been avoided since GStreamer would not be installed. The Ghostscript one would have been avoided as well, because the time frame where Ghostscript was unpatched was much smaller.

The above give us a good indication that Debian will suit us better than Alpine Linux in this regard (well, until a nasty libc bug bites us 😬 🧿)

Faster image builds

Debian includes PyMuPDF in its repos for both the amd64 and arm64 architectures, so we don't need to build anything from source.

More benefits

The reasons for switching to Debian Stable are not exhausted to the above key areas. What's also important for us is being able to build the container image reproducibly, which we cover in a separate issue.