Why would you not be pinning versions in a Dockerfile? The entire point is “if it works on my machine, it works on yours,” and that goes out the window if you can’t be assured that every program in the release is at the same version you had.

That "entire point" is already accomplished by the built binary container image, which has a unique identifier in the form of its SHA-256 hash, and can be shared with others easily.

A reproducible build is grand, but somewhat tangential to that goal, and hard to obtain in practice. Besides the timestamp problem already mentioned, you can't always pin the versions of system libraries and other distribution-provided software. The large long-term cost of hosting and geographically distributing content leads to many distributions, and especially their externally provided package mirrors, discarding stale versions from repositories. Often, the only available versions are the one included in the release plus the latest N, with N sometimes as small as 1.

If you're building a no-frills image for production deployment of a single piece of software, this problem can be bypassed thanks to distroless and other stripped-down base images, but "batteries included" images can't go this route.

Because if you pin versions you are pinning to some version with a security flaw that you are not allowing yourself to get. Often a flaw is fixed by a developer who realizes something is wrong with the code but it hasn't been exploited yet so anyone who keeps up to date cannot be exploited by that flaw, while anyone who doesn't keep up doesn't even know they are vulnerable.

Of course there is a balance here, there is a reason to pin versions. I'm stating why you shouldn't do that, but I cannot figure out all the pros and cons and how they should work out for your needs.

Reproducible docker images are almost useless for the things you want reproducible for. Sure you can reproduce the image for all of the future, but that image is useless in a few years when the certificates expire. Those expired certificates mean you cannot use the image for whatever you wanted it for.

A variation of the above is reproducible builds are not that useful - sure you can prove the build is the same, but in the end you want the latest security fixes applies and so by the time you create the replacement build and verify it the build is obsolete.

Don't get me wrong, reproducible builds are important and do good things - but there are severe limits to what you can/should do with them and so while it is important to demand them, they are not important to use yourself.

Wouldn't you want to have certificates and other crypto data as an input to a reproducible build harness?

  # build initial images
  # add semi-static inputs (mostly static config data, crypto data, signed inputs)
  # add final watermarks

So each step can be verified

That final watermark is not verifiable and so you can inject something else.

Can be, but aren't.

Are you pinning your base image? Where did that come from? Are you pinning your packages? What about their dependencies? Are you locking down the hashes or just hoping that your distro won't replace a package in-place?

And that's before you get into crap like OpenShift certification that blanket requires a `dnf update` statement.