4 ms·

can someone please elucidate the _benefits_ of reproducible builds ? perhaps i am missing something trivial? thank you kindly!

passionforfruit 5y ago
https://reproducible-builds.org/docs/buy-in/ https://reproducible-builds.org/docs/buy-in/
rocqua 5y ago
It ensures two important things. The first is that it makes sure any maintainers who try to backdoor a package need to document that fact somewhere in the build process. Hence it becomes possible to get more confidence from an audit of a package. This first goal is done very simply. You rebuild the package, and check that the resulting binary is bit-for-bit identical. With reproducible builds, the same build process should lead to the same binary. So if someone tampered with the source code or the build process, that can be detected if you have reproducible builds. The second goal is to just have a consistent system which makes debugging easier. A nice example of the importance of reproducible builds is the app signal, which I mention because of your user-name. We trust the source code of signal, but how are we supposed to be sure that the binaries offered by apt, the google play store, the app store, or whatever source you have for signal, are actually made from the source code? With reproducible builds, one person can rebuild the binary and check to see that the output is the same. This is much better than telling everyone to build signal from source, because now the lazy people who trust the binaries get to benefit from the skeptical people who build from source.
brnt 5y ago
I would turn that around: if your builds are irreproducable, how would you troubleshoot build errors?
goodpoint 5y ago
People already listed: - security against backdoors - validating build environment - reproducing bugs But there's more: - legal liabilities: many bad build systems pull trees of dependencies from the Internet during the build. How can you prove that no license breaching occurred in any of the dependencies? Debian explicitly verifies licensing in each package. - prevent pulling dependencies from deleted (or hijacked!) repositories on the Internet - reproduce performance improvements: non reproducible builds can often lead to non reproducible performance. Even things like the length of the local hostname can leak into a binary and affect memory alignment.
TacticalCoder 5y ago
The most important benefit is that if a build is reproducible, then a backdoored build is reproducible. The security benefits and security implications of being able to reproduce what bad guys have done are huge. And by having this "threat" against the bad guys, which consists in saying: "If you poison the well, we'll find how you did it", suddenly the bad guys are having a much harder time being bad.
Xophmeister 5y ago
This is a bit more niche than what the answers already posted mention, but reproducible builds ensure reproducible output from said software. This is important in scientific software as — presuming you have a deterministic model — you don’t want the same inputs giving different outputs because of some weird build artefact.
hyperman1 5y ago
They are important in the security world, to prove that the delivered executable corresponds to the source code. E.g. nobody added a keylogger after publishing the source but before compiling the executable.
0x0 5y ago
- it's a great way to be sure binaries aren't backdoored or built from unofficial sources - in general if you want to do additional development on a piece of software, it's useful to validate that your build environment is set up correctly and can reproduce bit-exact binaries, before doing additional development - it helps prevent silent environment-specific build dependencies creeping in, aka "works on my machine"
- calvinmorrison 5y ago
  The last point is exceedingly useful. If you build lots of in-house packages you may have forgotten what depends on what and when you go to say 'clean room' upgrade to a newer version of X, Y and Z don't work or X must be built first. Of course these simpler things are handled by proper dependencies but if you always build on a box designated "we built packages here" those lines can blur. Doing from scratch reproducable build enforces getting those things right from the start.
cute_boi 5y ago
Its very important in FOSS imo. There is FOSS called ungoogled chromium. And building chromium takes a lot of times (in my case 8 hours). The problem here is chromium build is not reproducible and repo author can't build chromium for every platform and every versions as its very expensive from him. So what he currently do now is accepts the binaries from others. But as a user how can I trust the user who build the binaries? He might have tempered with binaries? He might have inserted back doors secretly? Just because he published binaries lets say for 10 years doesn't grants 100% trustworthy right? He might be hacked etc too? I think reproducible builds fixes such problems. Other than trust factor I really don't think there is significant advantage.
- thakis 5y ago
  Chromium's build is reproducible: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/deterministic_builds.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...
  - cute_boi 5y ago
    Too strange. To confirm I went to https://github.com/Eloston/ungoogled-chromium https://github.com/Eloston/ungoogled-chromium it says "NOTE: These binaries are provided by anyone who are willing to build and submit them. Because these binaries are not necessarily reproducible, authenticity cannot be guaranteed;"
- gorgoiler 5y ago
  I don’t follow your example. Isn’t compile(src, platform) → binary a one way function? If someone kindly hands the repo author a (binary, platform) pair how would the author ever verify the original src value, other than re-doing the 8 hour compile themselves?
  - cute_boi 5y ago
    author can't verify , user can't verify that's why we need reproducible builds. if no reproducible builds then, sha256(binary_from_user1) != sha256(binary_from_user2) For smaller project distributing code source is usually correct choice as auditing src code is better than auditing binaries. But the project like chromium I think reproducible build is essential because you can't force everybody to compile and waste hours right?
Proven 5y ago
ffs how hard is it to select "reproducible builds" and right click to search for that

passionforfruit 5y ago

https://reproducible-builds.org/docs/buy-in/ https://reproducible-builds.org/docs/buy-in/

rocqua 5y ago

It ensures two important things. The first is that it makes sure any maintainers who try to backdoor a package need to document that fact somewhere in the build process. Hence it becomes possible to get more confidence from an audit of a package. This first goal is done very simply. You rebuild the package, and check that the resulting binary is bit-for-bit identical. With reproducible builds, the same build process should lead to the same binary. So if someone tampered with the source code or the build process, that can be detected if you have reproducible builds. The second goal is to just have a consistent system which makes debugging easier. A nice example of the importance of reproducible builds is the app signal, which I mention because of your user-name. We trust the source code of signal, but how are we supposed to be sure that the binaries offered by apt, the google play store, the app store, or whatever source you have for signal, are actually made from the source code? With reproducible builds, one person can rebuild the binary and check to see that the output is the same. This is much better than telling everyone to build signal from source, because now the lazy people who trust the binaries get to benefit from the skeptical people who build from source.

brnt 5y ago

I would turn that around: if your builds are irreproducable, how would you troubleshoot build errors?

goodpoint 5y ago

People already listed: - security against backdoors - validating build environment - reproducing bugs But there's more: - legal liabilities: many bad build systems pull trees of dependencies from the Internet during the build. How can you prove that no license breaching occurred in any of the dependencies? Debian explicitly verifies licensing in each package. - prevent pulling dependencies from deleted (or hijacked!) repositories on the Internet - reproduce performance improvements: non reproducible builds can often lead to non reproducible performance. Even things like the length of the local hostname can leak into a binary and affect memory alignment.

TacticalCoder 5y ago

The most important benefit is that if a build is reproducible, then a backdoored build is reproducible. The security benefits and security implications of being able to reproduce what bad guys have done are huge. And by having this "threat" against the bad guys, which consists in saying: "If you poison the well, we'll find how you did it", suddenly the bad guys are having a much harder time being bad.

Xophmeister 5y ago

This is a bit more niche than what the answers already posted mention, but reproducible builds ensure reproducible output from said software. This is important in scientific software as — presuming you have a deterministic model — you don’t want the same inputs giving different outputs because of some weird build artefact.

hyperman1 5y ago

They are important in the security world, to prove that the delivered executable corresponds to the source code. E.g. nobody added a keylogger after publishing the source but before compiling the executable.

0x0 5y ago

- it's a great way to be sure binaries aren't backdoored or built from unofficial sources - in general if you want to do additional development on a piece of software, it's useful to validate that your build environment is set up correctly and can reproduce bit-exact binaries, before doing additional development - it helps prevent silent environment-specific build dependencies creeping in, aka "works on my machine"

calvinmorrison 5y ago
The last point is exceedingly useful. If you build lots of in-house packages you may have forgotten what depends on what and when you go to say 'clean room' upgrade to a newer version of X, Y and Z don't work or X must be built first. Of course these simpler things are handled by proper dependencies but if you always build on a box designated "we built packages here" those lines can blur. Doing from scratch reproducable build enforces getting those things right from the start.

cute_boi 5y ago

Its very important in FOSS imo. There is FOSS called ungoogled chromium. And building chromium takes a lot of times (in my case 8 hours). The problem here is chromium build is not reproducible and repo author can't build chromium for every platform and every versions as its very expensive from him. So what he currently do now is accepts the binaries from others. But as a user how can I trust the user who build the binaries? He might have tempered with binaries? He might have inserted back doors secretly? Just because he published binaries lets say for 10 years doesn't grants 100% trustworthy right? He might be hacked etc too? I think reproducible builds fixes such problems. Other than trust factor I really don't think there is significant advantage.

thakis 5y ago
Chromium's build is reproducible: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/deterministic_builds.md https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...
- cute_boi 5y ago
  Too strange. To confirm I went to https://github.com/Eloston/ungoogled-chromium https://github.com/Eloston/ungoogled-chromium it says "NOTE: These binaries are provided by anyone who are willing to build and submit them. Because these binaries are not necessarily reproducible, authenticity cannot be guaranteed;"
gorgoiler 5y ago
I don’t follow your example. Isn’t compile(src, platform) → binary a one way function? If someone kindly hands the repo author a (binary, platform) pair how would the author ever verify the original src value, other than re-doing the 8 hour compile themselves?
- cute_boi 5y ago
  author can't verify , user can't verify that's why we need reproducible builds. if no reproducible builds then, sha256(binary_from_user1) != sha256(binary_from_user2) For smaller project distributing code source is usually correct choice as auditing src code is better than auditing binaries. But the project like chromium I think reproducible build is essential because you can't force everybody to compile and waste hours right?

Proven 5y ago

ffs how hard is it to select "reproducible builds" and right click to search for that