4 ms·

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 v

by dlor 3y ago

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.

Gasp0de 3y ago
If I need node.js 20 I will just use the node:20-bookworm image.
- dlor 3y ago
  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.
  - kristianpaul 3y ago
    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
  - xnyanta 3y ago
    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.
solarkraft 3y ago
That's cool, but aren't containers considered to be a workaround for exactly that problem?
- dlor 3y ago
  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.
  - Gasp0de 3y ago
    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?
    - dlor 3y ago
      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 :)
  - kristianpaul 3y ago
    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.
Rucadi 3y ago
Wouldn't then using nix be better? Or at least base the distro on nix?

by dlor 3y ago

Gasp0de 3y ago

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

dlor 3y ago
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.
- kristianpaul 3y ago
  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
- xnyanta 3y ago
  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.

solarkraft 3y ago

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

dlor 3y ago
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.
- Gasp0de 3y ago
  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?
  - dlor 3y ago
    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 :)
- kristianpaul 3y ago
  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.

Rucadi 3y ago

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