It looks like almost everyone here thinks this is wrong and poorly argued (as do I). A meta question to ponder: why did this get upvoted to the front page? Is it that upvoters tend to not read the articles whereas commenters do? Do people upvote stuff they think is wrong for the purpose of discussion?
You don’t need reproducible builds
51–60 of 179 posts
Re: You don’t need reproducible builds
#52Earlier quoted context omitted.
How many people pin the exact version of a system library they are using? Or of a binary used in the build process. Also, how many people run the build in a sandbox to avoid "interference" from the environment? Yes, this is all good practice, but I think very few people do it, because it's not easy.
Yeah, true. I was thinking of doing release builds in containers via the CI/CD pipeline, keeps the environment pretty static, but not completely static of course. But further: All of these things would still not be enough for the strictest definition (exact same binary), at least with normal compiler defaults afaik?
> All of these things would still not be enough for the strictest definition (exact same binary), at least with normal compiler defaults afaik?
Right, because of things like timestamps getting into the binary.
Re: You don’t need reproducible builds
#53It looks like almost everyone here thinks this is wrong and poorly argued (as do I). A meta question to ponder: why did this get upvoted to the front page? Is it that upvoters tend to not read the articles whereas commenters do? Do people upvote stuff they think is wrong for the purpose of discussion?
> A meta question to ponder: why did this get upvoted to the front page?
The author is a sort of expert in the field, if he's calling out reproducible builds as security theatre, it's worth discussing
Re: You don’t need reproducible builds
#54I think OP is coming from a different perspective than I (corporate bespoke solution builder) do. When I say "reproducible build" I mean a build that is the same on any machine (i.e. no special magic necessary to build a "official" version of the code). Too often in corporate environments, getting a local build or setting up a new build pipeline involves arcane black magic and/or copy/pasting weird libraries that can…
For this reason I’ve been dockerizing my builds for almost five years. I was late to the Docker party, but when I saw the benefits it brings to build pipelines, I was sold. It's true that a dockerized build isn’t any simpler than its non-dockerized ancestor, but at least there’s a Dockerfile that lays bare all the black magic and special sauce which goes into each build. And it can be version controlled to watch for…
While your Dockerfile helps you know how a project was built at a specific point in time, it's not going to work forever. Even if the file doesn't change over time, the build it produces will. It's mainly because of installing packages using something like "apt-get install $package". It also can change if the files you're adding with ADD or COPY change.
Re: You don’t need reproducible builds
#55So, we have source code for the signal app. We can audit that source code, to ensure no key-leakage occurs. Next, I install signal on my phone via the app store. How do I know the app I installed matches the source code that was audited? After all, google / Apple could decide / be forced to provide a modified binary. Reproducible builds work for that. Alternatively, consider debian. I ain't got time to compile every…
> Next, I install signal on my phone via the app store. How do I know the app I installed matches the source code that was audited? After all, google / Apple could decide / be forced to provide a modified binary. Reproducible builds work for that. At least on iOS it would be very hard to get a hash of the binary running on your phone, not possible without jailbreaking AFAIK? You could check it on your computer of cou…
> You could check it on your computer of course
App Store-distributed ipas can’t be decrypted without keys burned into iOS hardware, so you can’t decrypt them on a Mac without a jailbroken iOS device. (You can hash the encrypted binary but of course that’s pretty useless for reproducibility.)
This might be about to change since Apple has announced support for running iOS apps directly on Apple Silicon Macs?
Re: You don’t need reproducible builds
#56Earlier quoted context omitted.
You are making the case for source control and having no external dependencies like npm, but you don't need reproducible builds for that.
I've a feeling there's multiple definitions of build reproducibility going on here. I'm guessing you mean that it's not important to be have something byte for byte identical, but more to ensure that exactly the same build steps were run with the same source code? For most of us, that's what build reproducibility means, but I guess for a subset of users it means producing an identical binary.
Byte-for-byte identical builds is useful mainly because format-agnostic diffing tools are a lot easier to use. There are quite a lot of cases where something is not byte-for-byte identical merely because of a timestamp that affects nothing.
That said, I think it was (and perhaps still is, to many people) surprising just how many sources of irreproducibility exist. Timestamps and absolute build locations are obvious sources, and to some degree, generally don't have an effect. Iterating over file inode order (i.e., "for each file in directory {}") is usually innocuous, but it can cause link order issues and change ordering of static constructors--which can have drastic effects (both in terms of performance and actual functional changes) on the resulting binary.
But if your build process is going to unexpectedly change the encoding of text files [1], that's actually pretty terrifying. There are also cases where the compiler just seems to randomly choose how to optimize code [2]. Note that randomness isn't coming from an obvious "if rand() % 4" check here, but perhaps from something more subtle such as "we're iterating over a map whose keys are addresses of internal data structures, and we stop optimizing after hitting 1000 entries as the function is too big, and the addresses change because link order or ASLR."
[1] https://tests.reproducible-builds.org/debian/issues/unstable...
[2] https://tests.reproducible-builds.org/debian/issues/unstable...
Re: You don’t need reproducible builds
#57There’s another reason I think reproducible builds could all a lot of value: app stores. Right now, if I install from a normal app store (Apple, Google, Microsoft), there’s no real benefit to using open source apps. Even if I trust the app store, I have no way to confirm that the app binary matches the purported source. App stores could improve the situation by building apps themselves, but I think that would put the…
This is such an underrated improvement app stores could make, which would make a large impact for minimal effort. They already require signed binary submissions, just publish the hash so we can verify it!
Edit: it's a large impact for the tiny fraction of the population who's interested in verification, with no degradation of the experience for everyone else
Re: You don’t need reproducible builds
#58There’s another reason I think reproducible builds could all a lot of value: app stores. Right now, if I install from a normal app store (Apple, Google, Microsoft), there’s no real benefit to using open source apps. Even if I trust the app store, I have no way to confirm that the app binary matches the purported source. App stores could improve the situation by building apps themselves, but I think that would put the…
This is such an underrated improvement app stores could make, which would make a large impact for minimal effort. They already require signed binary submissions, just publish the hash so we can verify it! Edit: it's a large impact for the tiny fraction of the population who's interested in verification, with no degradation of the experience for everyone else
It could be bigger than that. Imagine a little badge for open-source apps that don’t use any closed-source SDKs. These apps could be prioritized in search, and the users would benefit: less garbage in simple apps and higher battery life.
This won’t directly drive income for the app store in question, but it may drive perceived value of the platform as a whole.
Re: You don’t need reproducible builds
#59Earlier quoted context omitted.
For this reason I’ve been dockerizing my builds for almost five years. I was late to the Docker party, but when I saw the benefits it brings to build pipelines, I was sold. It's true that a dockerized build isn’t any simpler than its non-dockerized ancestor, but at least there’s a Dockerfile that lays bare all the black magic and special sauce which goes into each build. And it can be version controlled to watch for…
While your Dockerfile helps you know how a project was built at a specific point in time, it's not going to work forever. Even if the file doesn't change over time, the build it produces will. It's mainly because of installing packages using something like "apt-get install $package". It also can change if the files you're adding with ADD or COPY change.
You don’t have to download the internet upon each build.
First, in a corporate environment it’s common to run builds backed by artifact servers that’ll cache just about anything.
Second, it’s easy to place files in a Docker build context (that’s just a $25 dollar way of saying “next to the Dockerfile”) that would have been downloaded from the internet, but are stored locally instead. This is easier said than done for some formats. Source tarballs? Easy. Anything Java or Debian that requires a pesky server which works a certain way? You’re going to have to use a caching artifact server.
Re: You don’t need reproducible builds
#60It looks like almost everyone here thinks this is wrong and poorly argued (as do I). A meta question to ponder: why did this get upvoted to the front page? Is it that upvoters tend to not read the articles whereas commenters do? Do people upvote stuff they think is wrong for the purpose of discussion?
Because there are good points. Reproducible builds are not everything some people think, but they are still useful. Knowing what is wrong with them is important.