upvote

points

by dev_l1x_be6 hours ago |
comments
upvoteby bluGill3 hours ago|
next
[-]
You are screwed either way. If you don't update your container has a ton of known security issues, if you do the container is not reproducable. reproducable is neat with some useful security benefits, but it is something a non goal if the container is more than a month old - day might even be a better max age.
reply
upvoteby tosti1 hours ago|
parent|
next
[-]
Why is there a need for a package manager inside a container at all? Aren't they supposed to be minimal?

Build your container/vm image elsewhere and deploy updates as entirely new images or snapshots or whatever you want.

Personally I prefer buildroot and consider VM as another target for embedded o/s images.

reply
upvoteby AntiUSAbah7 minutes ago|
parent|
[-]
So if i have a docker container which needs a handful of packages, you would handle it how?

I'm handling it by using a slim debian or ubuntu, then using apt to install these packages with necessary dependencies.

For everything easy, like one basic binary, I use the most minimal image but as soon as it gets just a little bit annoying to set it up and keep it maintained, i start using apt and a nightly build of the image.

reply
upvoteby dev_l1x_be2 hours ago|
parent|
prev|
[-]
I update my docker containers regularly but doing it in a reproducible, auditable, predictable way
reply
upvoteby tom13372 hours ago|
parent|
[-]
Could you explain how you achieve this?
reply
upvoteby beart53 minutes ago|
parent|
next
[-]
If you are on github/gitlab, renovate bot is a good option for automating dependency updates via PRs while still maintaining pinned versions in your source.
reply
upvoteby oefrha2 hours ago|
parent|
prev|
[-]
Chainguard, Docker Inc’s DHI etc. There’s a whole industry for this.
reply
upvoteby DuncanCoffee5 hours ago|
prev|
next
[-]
I know it's an anti-pattern, but what is the alternative if you need to install some software? Pulling its tagged source code, gcc and compile everything?
reply
upvoteby kandros3 hours ago|
parent|
next
[-]
Copying from another image is an under appreciated feature

FROM ubuntu:24.04

COPY --from=ghcr.io/owner/image:latest /usr/local/bin/somebinary /usr/local/bin/somebinary

CMD ["somebinary"]

Not as simple when you need shared dependencies

reply
upvoteby Filligree2 hours ago|
parent|
prev|
next
[-]
Run “nix flake update”. Commit the lockfile. Build a docker image from that; the software you need is almost certainly there, and there’s a handy docker helper.
reply
upvoteby klodolph2 hours ago|
parent|
next
[-]
Recently I’ve been noticing that Nix software has been falling behind. So “the software you need is almost certainly there” is less true these days. Recently = April 2026.
reply
upvoteby sestep1 hours ago|
parent|
[-]
Are you referring to how the nixpkgs-unstable branch hasn't been updated in the past five days? Or do you have some specific software in mind? (not arguing, just curious)
reply
upvoteby klodolph56 minutes ago|
parent|
[-]
It’s a variety of different software that just isn’t updated very often.

I don’t mind being somewhat behind, but it seems like there are a lot of packages that don’t get regular updates. It’s okay to have packages that aren’t updated, but those packages should be clearly distinguishable.

reply
upvoteby PunchyHamster2 hours ago|
parent|
prev|
[-]
oh, great, adding more dependency, and one that just had serious security problem
reply
upvoteby hexa5552 hours ago|
parent|
[-]
as if other sandboxing software is perfect
reply
upvoteby tosti1 hours ago|
parent|
[-]
Nothing is perfect. (FreeBSD jails come close but still no.)
reply
upvoteby bennofs4 hours ago|
parent|
prev|
next
[-]
Both Debian and Ubuntu provide snapshot mirrors where you can specify a date to get the package lists as they looked at that time.
reply
upvoteby bluGill3 hours ago|
parent|
[-]
Which is only useful for historical invesigation - the old snapshot has security holes attackers know how to exploit.
reply
upvoteby lloeki2 hours ago|
parent|
[-]
> the old snapshot has security holes attackers know how to exploit.

So is running `docker build` and the `RUN apt update` line doing a cache hit, except the latter is silent.

The problem solved by pinning to the snapshot is not to magically be secure, it's knowing what a given image is made of so you can trivially assert which ones are safe and which ones aren't.

In both cases you have to rebuild an image anyway so updating the snapshot is just a step that makes it explicit in code instead of implicit.

reply
upvoteby rowanG0775 hours ago|
parent|
prev|
next
[-]
With a binary cache that is not so bad, see for example what nix does.
reply
upvoteby Pay085 hours ago|
parent|
[-]
I don't really see how that's different from a normal binary install of a reproducible package. Especially with the lacking quality of a lot of Nix packages.
reply
upvoteby bandrami3 hours ago|
parent|
next
[-]
If you're in a situation where you want reproducibility you're using nix to build your own packages anyways, not relying on their packages
reply
upvoteby rowanG0775 hours ago|
parent|
prev|
[-]
It's not if you can pin the package. It gives you reproducable docker containers without having to rebuild the world. Wasn't that the entire question?
reply
upvoteby liveoneggs2 hours ago|
parent|
prev|
next
[-]
pretend you don't do it and add your extra software to the layer above
reply
upvoteby dev_l1x_be2 hours ago|
parent|
prev|
[-]
base image

software component image

both should be version pinned for auditing

reply
upvoteby rascul1 hours ago|
prev|
next
[-]
I disagree with that as a hard rule and with the opinion that it's an anti-pattern. Reproducible containers are fine, but not always necessary. There's enough times when I do want to run apt-get in a container and don't care about reproducibility.
reply
upvoteby malikolivier5 hours ago|
prev|
next
[-]
This is to solve such issues that I am using and running StableBuild.

It is a managed service that keeps a cached copy of your dependencies at a specific time. You can pin your dependencies within a Dockerfile and have reproducible docker images.

reply
upvoteby schonfinkel4 hours ago|
parent|
[-]
I don't wanna be that guy but...

NIX FIXES THIS.

reply
upvoteby dijit4 hours ago|
parent|
[-]
So does Bazel. :p
reply
upvoteby evanjrowley1 hours ago|
parent|
[-]
adding to the list, one exotic approach to this problem is stagex https://codeberg.org/stagex/stagex
reply
upvoteby bandrami3 hours ago|
prev|
[-]
This has been a solved problem for over two decades now with Nix but people can't be asked
reply
upvoteby dev_l1x_be2 hours ago|
parent|
[-]
It has been solved even without Nix for a long time, just laziness is probably why we are not doing it
reply