You don’t need reproducible builds
blog.cmpxchg8b.com
You don’t need reproducible builds
1–10 of 179 posts
Re: You don’t need reproducible builds
#2I think he's right about all the security arguments. It is definitely nice to have properly reproducible builds from a build system point of view though. Things like ccache would work a lot more reliably.
Re: You don’t need reproducible builds
#3> What isn’t clear is what benefit the reproducibility provides.
The ability to cache build artefacts is a pretty huge benefit for my work.
Re: You don’t need reproducible builds
#4I 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't be pulled from any sort of "official" repository. curl/bash libraries that "automatically change versions" based on when upstream decides to change them can wreak havok when setting up a new build environment. My $0.02, it's not (in the corporate world) so much about validating binaries, but more about "how many steps beyond check out the code" exist and how easily can I validate my binary uses the same versions of libraries/dependencies as the one that a local developer tested?
Re: You don’t need reproducible builds
#5The arguments "don't follow." Reproducible builds were indeed more than once used to verify that the published binary does correspond to the published source.
Without having them, that kind of verification is much harder, depending on the build setup used, it can be even too hard to be achieved at all.
So we do have clear advantages of having the build infrastructure which results in reproducible builds, and I don't see anything that can substitute that.
The argument "if you build yourself from the sources, your build is then trusted" is not reflecting the reality. Most of the users are never going to build from the sources. Having reproducible builds, only a few people have to build from the sources to verify the binaries for the vast majority. Not to mention that without reproducibility, you can't even know if your own build environment is misconfigured.
Re: You don’t need reproducible builds
#6I 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…
It’s a well-defined term though
Re: You don’t need reproducible builds
#7I don't know about the 'formal' description of reproducible builds used in the article from a security perspective, but I do know that having the exact same output locally as is being built by a deployment process makes debugging a lot more straightforward because it removes the subtle and hard-to-discover problem of having slightly different library versions in your application making things perform differently.
Re: You don’t need reproducible builds
#8I 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 drift over time.
This stuff is useful in a corporate setting, but the other fetishization of reproducible builds is just a distraction that can stay where it belongs: open source mailing lists.
Re: You don’t need reproducible builds
#9I think he's right about all the security arguments. It is definitely nice to have properly reproducible builds from a build system point of view though. Things like ccache would work a lot more reliably.
Also just increased confidence that the build is working properly.
I think there's added security for the first party builder in their own process: they can better audit the process from source code to deployment.
Re: You don’t need reproducible builds
#10> Q. If a user has chosen to trust a platform where all binaries must be codesigned by the vendor, but doesn’t trust the vendor, then reproducible builds allow them to verify the vendor isn’t malicious.
> I think this is a fantasy threat model. If the user does discover the vendor was malicious, what are they supposed to do?
> The malicious vendor can simply refuse to provide them with signed security updates instead, so this threat model doesn’t work.
For me, this is one of the primary benefits of reproducible builds and the author's dismissal of it as fantasy is unconvincing.
Vendors trade on trust. If a reputable application uses reproducible builds and discovers that a platform vendor is modifying their application on their platform, that information is damaging to that vendor's reputation. That's extremely useful leverage against potentially malicious vendors.