←back to thread

Debian bookworm live images now reproducible

(lwn.net)
764 points bertman | 1 comments | 26 Mar 25 17:22 UTC | HN request time: 0s | source
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 #
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 #
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 #
1. ahlCVA ◴[28 Mar 25 00:22 UTC] No.43499869{3}[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.