Comment by dlor | Hacker News Reader

Comment by dlor | Hacker News Reader

Parent Full thread

Debian does a great job! But here's one example where their packaging system makes container workloads hard. Debian, like many other distros has a strict "one version of every package" rule, meaning that Debian only ships one version of common things like programming languages or webservers.

If you "apt-get install nodejs", you can only have Node.js v18, in the very very recently released Debian bookworm. If your devs need Node.js v20, or even v22 which will both be LTS releases during the bookworm release cycle, you're out of luck.

You can go install those outside of the Debian package manager, but then you're on your own for vuln assessment and security fixes. Worse - many scanners don't actually even "see" packages that are installed outside of package managers, so you may not know that these exist or are installed.

We designed Wolfi to be more flexible around package versions. This is a very very hard problem to solve in general, but since we're focused on immutable containers, we can skip a lot of the complexity around conflicts, upgrade/downgrade scenarios, and cross-version compatibility.

That's cool, but aren't containers considered to be a workaround for exactly that problem?

Yep, but workarounds come with a cost. We're trying to package basically everything, so you don't need to pick between "up to date software" and "software from a trusted distro".

It's going to be hard to scale, but we're going to at least try! We have a lot of ideas on how to make this work that I'm excited to try out.

So you want to provide all the up to date software, but as battle tested as the software included in the debian repos, with a few people?

Roughly yes! I think we have a few advantages - mainly that we're focused on container workloads - that simplify the problem. But otherwise, yes!

I'm betting that with enough automation we can get there :)

We can always come back to the discussion of statically linked vs dynamically. If your build system is strong an can adapt to these changes thats another option.

Wouldn't then using nix be better? Or at least base the distro on nix?

If I need node.js 20 I will just use the node:20-bookworm image.

And the fun part there is that this image is effectively a workaround - node.js 20 is installed via curl | bash. That means CVE scanners and SCA tools can miss node itself in that image.

As silly as it sounds, try running "snyk container test --print-deps" on that image, and look around for Node.

This approach works fine, but means that you might not be able to rely on most container security scanners to let you know when there's an issue.

You can scan the file system, probably thats what AWS ECR does?

At the end of they you need to keep an eye on file integrity, because of rootkits, config integrity…

Yeah there are many wats to approach to this… with its corresponding costs of course

Sounds to me like CVE scanners aren't doing a great job if they can't pick up a nodejs installation from the official nodejs image distribution. Just looking at package manager metadata effectively won't give you the full picture.

Reply on news.ycombinator.com