←back to thread

193 points dopple | 2 comments | | HN request time: 0.404s | source
Show context
kayson ◴[] No.43745417[source]
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

replies(5): >>43745702 #>>43745767 #>>43747454 #>>43747703 #>>43751011 #
1. jcastro ◴[] No.43747454[source]
> 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.

replies(1): >>43756438 #
2. kayson ◴[] No.43756438[source]
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...