You don’t need reproducible builds • Hacker News Board

Re: You don’t need reproducible builds

#141

Post by karmakaze » Wed, Aug 05, 2020, 9:32 PM UTC

This post misses so much.

"What isn’t clear is what benefit the reproducibility provides. The only way to verify that the untrusted binary is bit-for-bit identical to the binary that would be produced by building the source code, is to produce your own trusted binary first and then compare it. At that point you already have a trusted binary you can use, so what value did reproducible builds provide?"

Being able to reproduce a build not only validates the source but the entire process of creating the executed artifact. To properly capture this ability and value the CI/CD pipeline should also be reproducible in an infrastructure-as-code manner. Together with the programs' source and short documentation (as it should be coded) on how to put these parts together it means the operation of the company can be recreated in another geography/datacenter and continue to work while team members rotate out/in.

Contrast the situation with inheriting a codebase that only has possibly matching source code and a production environment that everyone is afraid to touch at the other extreme.

Re: You don’t need reproducible builds

#142

Post by TwoBit » Wed, Aug 05, 2020, 9:34 PM UTC

ex_amazon_sde wrote: post #19

A number of large companies are quietly moving towards reproducible build. Sorry if I cannot name the names. As a side note, reproducible builds implemented in Debian were also useful to spot various other problem: small differences in build environment that would make debugging more difficult. Sometimes the same application will have different performance depending on the build due to memory alignment, data ordering…

> A number of large companies are quietly moving towards reproducible build. Sorry if I cannot name the names.

Thanks, user "ex_amazon_sde"!

Re: You don’t need reproducible builds

#143

Post by crb002 » Wed, Aug 05, 2020, 9:36 PM UTC

Define reproducible. I always archive dependencies so I can rebuild, even if that build has some new timestamps in it. Having a rando Github repo go down when you rebuild is not a failure mode I want.

Re: You don’t need reproducible builds

#144

Post by joshuamorton » Wed, Aug 05, 2020, 9:37 PM UTC

withinboredom wrote: post #137

joshuamorton wrote: post #88

Earlier quoted context omitted.

No, I'm saying you re-run your automated unit tests on the release build because there's no reason not to. If you have test failures in opt/stripped mode, they're more annoying to debug yes, but wouldn't you want to know? Another way of putting this is that when you > - Build and link your tests code into a library artifact. You build and link the same object files that will be built into the release binary artifact,…

> I, uhh, usually do this in my released software too. Do you have any idea how annoying it is to get logged garbage when starting something on the command line (looking at you IntelliJ)? I once spent several weeks hunting through Hadoop stack traces for a null pointer exception that was being thrown in a log function. If the logging wasn’t being done in production, I wouldn’t have wasted my life and could have been…

Yes, which is why I regularly (think quarterly or annually) check to make sure we have good log hygiene, and are logging at appropriate log levels and not logging useless information.

I have alerting set up to page me if the things I care about start logging more than the occasional item at ERROR, so I have to pay some attention or I get pestered.

Re: You don’t need reproducible builds

#145

Post by Markoff » Wed, Aug 05, 2020, 9:45 PM UTC

interesting choice of domain name, any background?

Re: You don’t need reproducible builds

#146

Post by nhoughto » Wed, Aug 05, 2020, 9:47 PM UTC

Diggsey wrote: post #13

There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…

Just the build caching is worth the price of entry.

Gradle especially does a great job at this.

Re: You don’t need reproducible builds

#147

Post by remexre » Wed, Aug 05, 2020, 9:57 PM UTC

SkyBelow wrote: post #108

Diggsey wrote: post #13

There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…

>If a binary is lost, it can be rebuilt exactly as it was. You only need to ensure the source is preserved. Wouldn't this depend upon the environment as well? Unless the build starts off by creating a build environment, but then we are half way to "To first make bread from scratch, create a universe...".

If you run your builds in Docker, this is usually taken care of.

If not, it seems like it'd be good practice to document exactly what build dependencies are used; I've had to track down a regression introduced by inlined code from a dependency when we weren't tracking build dependency versions, and the fact that a bug was introduced with no changes in the relevant section of the code was troublesome to say the least.

Re: You don’t need reproducible builds

#148

Post by cmckn » Wed, Aug 05, 2020, 9:58 PM UTC

nhoughto wrote: post #146

Diggsey wrote: post #13

There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…

Just the build caching is worth the price of entry. Gradle especially does a great job at this.

Tangential, but I actually switched back to Maven after using Gradle on a fairly large project for about a year. The incremental/cached builds of Gradle were awesome, but I found writing build.gradle files to be a bit too hacky. I can achieve everything I need to with some simple configuration of an existing Maven plugin, whereas with Gradle, it always felt like I was doing something super custom and fragile.

I'd still love to set up a Gradle cache server, sounds so fancy!

Random piece of Gradle magic, a generated BOM: https://github.com/grpc/grpc-java/blob/master/bom/build.grad...

Re: You don’t need reproducible builds

#149

Post by Willamin » Wed, Aug 05, 2020, 10:01 PM UTC

pests wrote: post #139

R0b0t1 wrote: post #99

Earlier quoted context omitted.

The holy grail of reproducible builds is achieving the same binary via different compilers. This was, at least when I started looking into reproducible builds, why I wanted to do it and why others wanted to do it. The other benefits are kind of side benefits.

This can't be correct. What would be the point of different compilers be then? There's no way that every compiler would produce the same exact insrtuctions for each respected input. There would be no point to using an optimizing compiler or one with better intrinsic support.

> What would be the point of different compilers be then?

When given the same input and expecting the same output, there remains only one thing: compile speed.

Re: You don’t need reproducible builds

#150

Post by wwweaponizer » Wed, Aug 05, 2020, 10:05 PM UTC

Reproducible builds allow people to independently verify that a build came from the source code that the binary vendor claims it did, rather than some compromised source code.