4 ms·
> it's the same as "curl | bash" While I understand the argument you're making, the exposure of running "curl | bash" on your local machine is much higher than
by radlad 3y ago
> it's the same as "curl | bash"
While I understand the argument you're making, the exposure of running "curl | bash" on your local machine is much higher than running arbitrary code inside of a container.
Even if you specify a hash, are you actually checking all of the code and binaries in that image?
What about the image base (e.g. Alpine, Debian) and their packages?
- pphysch 3y agoThere have been a lot of container escape exploits
- radlad 3y agoSure... but it's still not "the same as" running on your host.
- TeMPOraL 3y agoThat depends on how you're running it. You wouldn't want a compromised image to be the base for your build containers, which get access to your product's source code via volume mount, or to secret keys via environment variables.
- peterbecich 3y agoI'm a big fan of Nix Flakes but they appear to have the same issue here as "curl | bash". I mention this because Flakes can do much of what Docker can do, but do not use containers or virtualization. The official NixPkgs are carefully vetted. Nix Flakes make it more convenient to pull in sources from outside NixPkgs. As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them. There are more benefits to Nix Flakes than native execution so containerizing them somehow might be an acceptable compromise.
- one-punch 3y ago> As Nix Flakes become more prevalent, perhaps there needs to be some way to containerize them. You may be interested in nix snapshotter, which can run nix packages in containerd. https://news.ycombinator.com/item?id=37407758 https://news.ycombinator.com/item?id=37407758