<div dir="ltr">> - docker - currently unusable, messes up some timestamps when exporting<span class="gmail-Apple-converted-space"> </span><br>> layers, not respecting SDE on every level<br><div><br></div><div>This is not true.</div><div>You can use the <span style="font-family:"roboto flex mono",ui-monospace,SFMono-Regular,monospace;font-size:12.25px;white-space:nowrap;background-color:rgb(231,234,239)">rewrite-timestamp</span> option to export the layers with SOURCE_DATE_EPOCH</div><div><a href="https://docs.docker.com/build/exporters/image-registry/">https://docs.docker.com/build/exporters/image-registry/</a><br></div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">2026年1月28日(水) 8:09 cen <<a href="mailto:imbacen@gmail.com">imbacen@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I've been dabbling in this topic for the past year, weak on theory but <br>
have some practical experience.<br>
<br>
<br>
The results of the first study do not surprise me at all, unless you <br>
construct the Dockerfile to be reproducible, it won't magically be <br>
reproducible and most downstream developers don't consider it.<br>
<br>
Just from personal experience, most of my colleagues haven't even heard <br>
about the reproducible builds in general, let alone about reproducible <br>
docker images. :)<br>
<br>
 From that aspect, trying to reproduce the hub or ghcr seems like a <br>
futile experiment.<br>
<br>
Bit-for-bit reproducibility is achievable if you strictly follow most of <br>
these steps:<br>
<br>
- the first and obvious condition is that your project/binary that you <br>
are packaging is reproducible (most Dockerfiles probably already fail <br>
because of this step)<br>
<br>
- pin FROM to sha256, use multi stage builds, consider using distroless <br>
image for final<br>
<br>
- use a reproducible distro as builder base (e.g. Debian with snapshot <br>
repos turned on)<br>
<br>
- normalize all COPY commands with --chown and --chmod (from build step <br>
to final step)<br>
<br>
- if you install any additional packages in the final step, clean up <br>
after package manager (logs, cache) and normalize fs timestamps (touch <br>
-d "@${SOURCE_DATE_EPOCH}")<br>
<br>
<br>
If you miss any of these steps, your image won't be bit-for-bit <br>
identical. There is a chance it could be semantically identical though <br>
(diffoci diff --semantic).<br>
<br>
<br>
When it comes to tooling, ranked from best to worst in actually <br>
producing bit-for-bit identical images, based on my experience:<br>
<br>
- kaniko with SOURCE_DATE_EPOCH and --reproducible flag<br>
<br>
- podman with --timestamp "$SOURCE_DATE_EPOCH" --build-arg <br>
SOURCE_DATE_EPOCH="$SOURCE_DATE_EPOCH"<br>
<br>
- docker - currently unusable, messes up some timestamps when exporting <br>
layers, not respecting SDE on every level<br>
<br>
<br>
Unfortunately kaniko is currently in maintenance mode (abandoned by <br>
google and picked up by chainguard) but it works and doesn't require <br>
root so it's perfect for CI pipelines.<br>
<br>
<br>
I am not sure how big of an issue the cosign situation is.<br>
<br>
I can build the same image in CI and locally, push them to two different <br>
registries and obtain the same digest on both. That seems reproducible <br>
to me even if not strictly locally.<br>
<br>
<br>
Best regards,<br>
<br>
Klemen/cen1<br>
<br>
<br>
On 25/01/2026 20:48, kpcyrd wrote:<br>
> Dear list,<br>
><br>
> I found this in my news feed and wanted to share:<br>
><br>
> - <a href="https://arxiv.org/pdf/2601.12811" rel="noreferrer" target="_blank">https://arxiv.org/pdf/2601.12811</a><br>
> - <a href="https://dl.acm.org/doi/10.1145/3736731.3746146" rel="noreferrer" target="_blank">https://dl.acm.org/doi/10.1145/3736731.3746146</a><br>
><br>
> For people reading along who are not super familiar with the topic, <br>
> note there's a distinction between "Docker image" and "Dockerfile":<br>
><br>
> - the Docker image is the compiled artifact<br>
> - the Dockerfile is a file with build instructions<br>
><br>
> The Docker image is what you get out of `docker build`, but since this <br>
> is essentially just a tar file you could also use something like <br>
> apko[0] to generate them. From what I understand this is a fairly <br>
> straight-forward way to repack your binary, without having to involve <br>
> yourself with namespaces, kernel capabilities and base images.<br>
><br>
> At that point you only need to worry about reproducible builds for <br>
> your executable.<br>
><br>
> [0]: <a href="https://github.com/chainguard-dev/apko" rel="noreferrer" target="_blank">https://github.com/chainguard-dev/apko</a><br>
><br>
> The Dockerfile is what most people use to build their containers, this <br>
> technology also notably doesn't have a dependency lockfile like you <br>
> are used to with modern programming language package managers.<br>
><br>
> This is also what the paper mostly (but not exclusively) focuses on.<br>
><br>
> Lastly, there's also another problem[1] that I see very rarely talked <br>
> about - if you can build your Docker image on two different computers <br>
> with bit-for-bit identical outputs, this still does *not* mean you can <br>
> independently authenticate the contents of a container registry.<br>
><br>
> The image is only fully "built" after it has been published to the <br>
> registry, since the manifest file is being re-written by the registry <br>
> (in an undefined/unspecified way). This is, in my opinion, the biggest <br>
> problem in the Docker/container ecosystem, the other ones we can work <br>
> around by switching from `docker build` to different tools if we have to.<br>
><br>
> [1]: <a href="https://github.com/sigstore/cosign/issues/2516" rel="noreferrer" target="_blank">https://github.com/sigstore/cosign/issues/2516</a> (2022)<br>
><br>
> ---<br>
><br>
> I would love to get some input on this, especially if I got anything <br>
> wrong or if there has been progress on authenticating the content of <br>
> e.g. <a href="http://hub.docker.com" rel="noreferrer" target="_blank">hub.docker.com</a> (or <a href="http://ghcr.io" rel="noreferrer" target="_blank">ghcr.io</a> for that matter).<br>
><br>
> The authors of the paper are also most likely subscribed here (hi!).<br>
><br>
> Very interested,<br>
> kpcyrd<br>
</blockquote></div>