←back to thread

Debian bookworm live images now reproducible

(lwn.net)
766 points bertman | 6 comments | 26 Mar 25 17:22 UTC | HN request time: 1.045s | source | bottom
Show context
c0l0 ◴[26 Mar 25 17:43 UTC] No.43484720[source]▶
I never really understood the hype around reproducible builds. It seems to mostly be a vehicle to enable tivoization[0] while keeping users sufficiently calm. With reproducible buiilds, a vendor can prove to users that they did build $binary from $someopensourceproject, and then digitally sign the result so that it - and only it - would load and execute on the vendor-provided and/or vendor-controlled platform. But that still kills effective software freedom as long as I, the user, cannot do the same thing with my own build (whether it is unmodified or not) of $someopensourceproject.

Therefore, I side with Tavis Ormandy on this debate: https://web.archive.org/web/20210616083816/https://blog.cmpx...

[0]: https://en.wikipedia.org/wiki/Tivoization

replies(12): >>43484745 #>>43484754 #>>43484942 #>>43485078 #>>43485108 #>>43485155 #>>43485403 #>>43485551 #>>43485635 #>>43486702 #>>43487034 #>>43492779 #
1. ahlCVA ◴[26 Mar 25 18:19 UTC] No.43485155[source]▶
For me as a developer, reproducible builds are a boon during debugging because I can be sure that I have reproduced the build environment corresponding to an artifact (which is not trivial, particularly for more complex things like whole OS image builds which are common in the embedded world, for example) in the real world precisely when I need to troubleshoot something.

Then I can be sure that I only make the changes I intend to do when building upon this state (instead of, for example, "fixing" something by accident because the link order of something changed which changed the memory layout which hides a bug).

replies(1): >>43490024 #
2. signa11 ◴[27 Mar 25 03:11 UTC] No.43490024[source]▶
so what you are looking for is reproducible build environment ? things like docker have been around doing just that for a while now.
replies(3): >>43491514 #>>43491651 #>>43499869 #
3. turboponyy ◴[27 Mar 25 08:43 UTC] No.43491514[source]▶
Docker can be used to create reproducible environments (container images), but can not be used to reproduce environments from source (running a Dockerfile will always produce a different output) - that is, the build definition and build artifact are not equivalent, which is not the case for tools like Nix.
4. myrmidon ◴[27 Mar 25 09:11 UTC] No.43491651[source]▶
> things like docker have been around doing just that for a while now.

Thats just not enough. If you are hunting down tricky bugs, then even extremely minor things like memory layout of your application might alter the behavior completely-- some uninitialized read might give you "0" every time in one build, while crashing everything with unexected non-zero values in another; performance characteristics might change wildly and even trigger (or avoid) race conditions in builds from the exact same source thanks to cache interactions, etc.

There is a lot of developer preference in how an "ideal" processs/toolchain/build environment looks like, but reproducible builds (unlike a lot of things that come down to preference) are an objective, qualitative improvement-- in the exact same way that it is an improvement if every release of your software corresponds to one exact set of sourcecode.

replies(1): >>43494239 #
5. nottorp ◴[27 Mar 25 14:47 UTC] No.43494239{3}[source]▶
And he said embedded.

That means it crashes on some device that is on a pole in the middle of nowhere, or in a factory where you have to wear armor to go debug it on site.

Docker is cushy ... for servers and developer machines.

6. ahlCVA ◴[28 Mar 25 00:22 UTC] No.43499869[source]▶
I see reproducible builds more as a contract between the originator of an artifact and yourself today (the two might be the same person at different points in time!) saying "if you follow this process, you'll get a bit-identical artifact to what I have gotten when I followed this process originally".

If that process involves Docker or Nix or whatever - that's fine. The point is that there is some robust way of transforming the source code to the artifact reproducibly. (The less moving parts are involved in this process though the better, just as a matter of practicality. Locking up the original build machine in a bank vault and having to use it to reproduce the binary is a bit inconvenient.)

The point here is that there is a way for me to get to a "known good" starting point and that I can be 100% confident that it is good. Having a bit-reproducible process is the no-further-doubts-possible way of achieving that.

Sure it is possible that I still get an artifact that is equivalent in all the ways that I care about if I run the build in the exact same Docker container even if the binaries don't match (because for example some build step embeds a timestamp somewhere). But at that point I'll have to start investigating if the cause of the difference is innocuous or if there are problems.

Equivalence can only happen in one way, but there's an infinite number of ways to get inequivalence.