The Joy of Linux Theming in the Age of Bootable Containers

I really like the idea of immutable Linux and bootable containers. My next project will probably be switching to bazzite. But I took a look at the Containerfile[1], and I have some big concerns about the fragility of their supply chain. It uses 20 different copr repos (granted, half are their own), and I didn't count how many packages. Best I can tell, none of the versions are pinned. They do dump a diff of all package versions in the release notes[2], but I wonder if anyone actually reviews it before release. All it takes is one vulnerability in one repo / package and you can enjoy your new cryptominer.

There's something nice about running Debian and having confidence in all the packages because they're built and maintained by the Debian team. Of course there are exceptions, but in my experience they're rare. The only non-standard repo I regularly use is fish shell, and the updates are so few and far between (and very public) I think the risk is low.

I suppose this isn't strictly a container-specific problem; you could add the repos and install / update all those packages yourself too. But being able to package everything up into a single file that you can then boot into as your OS means you're also packing all the supply chain risk.

Curious if anyone else shares my concern or if I should just put my tinfoil hat back on...

1. https://github.com/ublue-os/bazzite/blob/main/Containerfile 2. https://github.com/ublue-os/bazzite/releases/tag/42.20250417

Nothing holds you from using bootable containers in the same way you use Debian and only use packages from the official Fedora repositories, starting from Fedora's bootc base images.

> Best I can tell, none of the versions are pinned.

From your link, everything is pinned? So a theoretical exploit in a future release of package is not going to exist in this immutable release https://github.com/ublue-os/bazzite/releases/tag/42.20250417

Right but everytime a new immutable release is created, it automatically pulls the latest version of every package. It's not a manual change of package versions.

Yeah I think that may be what I end up doing.

I mean that's the big lie isn't it? We all know no one is actually looking at these.

Every system which tells me how immutable it is then shows me it's automatic version bump script or something.

> It uses 20 different copr repos (granted, half are their own), and I didn't count how many packages. Best I can tell, none of the versions are pinned.

Contributor here, we've been working on this diligently over the past cycle (the rest of the org is mostly done, Bazzite is largest so we're only getting to it now). We're hoping to be done over the summer with published SBOMs and all that good stuff.

I agree with your concerns—at least, last time I looked.

I looked over their code, saw some things (I believed) I would do differently, and it was very easy to make my own personal spin to use.

After doing that, maintaining it, and using it daily for the last year I went back on some of my original choices. I feel much less critical of the decisions Jorge Castro made and it's probably time to compare and contribute if I can. Like, Homebrew on Linux ended up being way better than I expected. But some things I liked better my way. Say, including the signing keys for Chrome's 3rd-party repo statically instead of fetching them over the network. (Writing this from my phone I don't exactly remember how they do/did it.)

Overall, I'd recommend trying it yourself! It's been a ton of fun.

> Say, including the signing keys for Chrome's 3rd-party repo statically instead of fetching them over the network.

This is a fantastic idea, it sucks to have an upgrade blocked by a slow repo, if you wouldn't mind filing an issue or sending a PR I'd love to have this. Thanks for the feedback!

I switched from official Fedora images when I got sick of dealing with nonfree stuff like codecs and nvidia drivers. They have much more lightly modified images that are better as a base to build on. I use https://github.com/ublue-os/main (and https://github.com/ublue-os/hwe for an nvidia system).

The current term being used is "atomic" for this reason.

That's good to hear; I'm definitely a fan of SBOMs. But it doesn't fully address the risk introduced with automatic selection of the latest package version. If a package has no dependencies, for example, the SBOM wouldn't change if it were compromised with something that's compiled in to the package...