gomodjail VS Moby

Docker networking defaults have been tightened up but per https://github.com/moby/moby/issues/22054#issuecomment-28714...:

the default binding address is still 0.0.0.0.

There are now rules in raw-PREROUTING to drop packets sent from outside the host to container addresses, and to ports mapped to the loopback address. Rules in the filter-FORWARD chain no longer depend on its default policy.

Yeah, while I’ve seen some great libraries that follow the practice of minimizing their dependencies, I’m a bit annoyed with the amount of dependencies that docker will bring along [1]. I’ve been on the lookout for alternatives for my docker needs, but the state of podman, buildah and some others that I checked is similar. They all bring in roughly the same number of dependencies… if anyone knows of a stripped down Go lib that can be used to build from a Dockerfile, pull, and run a container, I would be grateful for any suggestions. Heck docker / moby isn’t even using go.mod proper.

[1] https://github.com/moby/moby/blob/master/vendor.mod

As far as I can tell from https://github.com/moby/moby/issues/4032, as of Debian 12 "bookworm" and Ubuntu 23.04 "Lunar", explicitly setting DEBIAN_FRONTEND is no longer necessary.

It's not an alpine layer, it's a Dockerfile construct representing basically an empty tar file layer: <https://docs.docker.com/build/building/base-images/#create-a...> and <https://github.com/moby/moby/pull/8827>

Manifests are tacked on afterwards, and have a lot of complexity that I'm not sure most folks have actually thought through.

Ex - lots of refs are to "multi-arch" images, Except... there's no such thing as a multi-arch image, the entire identifier is just a reference to a manifest that then points to a list of images (or other manifests) by arch, and the actual resolved artifact is a single entry in that list.

But it means the manifest needs to be able to reference and resolve other names, and that means including... names.

For a more concrete example, just check https://github.com/moby/moby/issues/44144#issuecomment-12578...

Basically - the digests weren't intended to support image verification across repos, and the tool doesn't treat them that way. The digest was intended to allow tighter specification than a tag (precisely because a publisher might push a different container to the same tag later).

If we run the command without -i option (i.e. with only -t option), a pseudo-TTY will be allocated and the shell will start, but no commands can be accepted and we cannot continue the operation because STDIN is disabled. To forcefully exit from a container in this state, we need to send three consecutive SIGINT signals by pressing cmd + . same times. And this exiting does not trigger the automatic container removal provided by --rm option, so we need to trigger it by stopping the container or remove the container directly.

Docker has a known security issue with port exposure in that it punches holes through the firewall without asking your permission, see https://github.com/moby/moby/issues/4737

I usually expose ports like `127.0.0.1:1234:1234` instead of `1234:1234`. As far as I understand, it still punches holes this way but to access the container, the attacker would need to get a packet routed to the host with a spoofed IP SRC set to `127.0.0.1`. All other solutions that are better seem to be much more involved.

When using the Docker Engine on Linux directly, based on the Moby project, you can run