Hacker News Reader

Comment by joshuamorton | Hacker News Reader

Note: This article is not talking about deterministic builds (which are a prerequisite for reproducible builds), but specifically reproducible builds.

Reproducible builds are generally speaking interesting only from a security perspective, while deterministic builds have all sorts of useful infrastructural features which the author agrees are useful.

And if you think I'm being pedantic, I'm using the official terminology from the reproducible builds site[0].

[0]: https://reproducible-builds.org/

View on HN

You're semantically right, but also missing the point. The expense of getting to deterministic builds is large - You have to take great care in your build infrastructure and scripts. The benefits are also large, and worth it.

Once you've gotten to deterministic builds, the expense of getting to reproducible builds is small; Typically days worth of work as opposed to months. The benefits are very different, but far from insignificant, and almost invaluable from a security perspective.

If you're going to do deterministic builds, go for broke - Do reproducible builds.

What is the difference?

Deterministic build means every time you compile the same source you get the same executable. Reproducible build means that you specify and relay enough information to allow everyone else to reproduce your results for themselves in their own environment.

Haha thanks.

So one has hidden variables that happen to be locally constant, and the other is purged of hidden variables.

It really depends. If I’m building a Java project, I’m pretty sure I’ve got a deterministic build just by running javac pointed at a source directory. If I want a reproducible build, I probably need to do a lot more:

- ensure timestamps of all files embedded in jar files is consistent

- ensure there is no BuildTime/BuildHost/BuildNumber variable of any kind being captured

- ensure the exact version of compiler is documented

- ensure exact versions of all dependencies in classpath is captured

Like the GP says, I can't imagine that would take more than a few days, even for a very large project with many dependencies.

There's an interesting pattern I've found in this: Don't ensure that there's no BuildTime/BuildHost/BuildNumber embedded. Ensure that all variables that are part of the build are captured and embedded. That is - It's okay for your build to include the Build Time, but that's an assertion at build time. Include it as a build output. Binaries should include all of the mutable environment used to build them as an embed. As in, their --version output should include them.

    # bazel version
    Build label: 2.0.0
    Build target: bazel-out/darwin- opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
    Build time: Thu Dec 19 12:33:30 2019 (1576758810)
    Build timestamp: 1576758810
    Build timestamp as int: 1576758810

Reply on news.ycombinator.com