3 ms·

Why didn't you just build from source, and then use those binaries? What did the reproducibility add?

by taviso 5y ago

uncletaco 5y ago
A verification step. Download the binary of a package as well as its source and build the source, if the resulting binary matches the hash of the other binary then you’ve just reproduced it and can consider it verified.
- taviso 5y ago
  You have the source, you have a binary that you've produced from that source, and you have a binary that someone else claims was produced from that source. You know without doubt that the binary that you produced was built from the source code, because you built it. I'm asking, why not stop there? You have a binary that you can safely consider "verified", what does it matter if it's bit-for-bit identical to any other binaries?
  - akshayshah 5y ago
    Depends on the situation. In some cases, the old binary (that someone claims was built from the available source) is out in production doing useful things. Perhaps it’s been there for years. If it’s not built from the source you have available, you first have to figure out where the current binary came from and how to safely change it.
  - smasher164 5y ago
    For me, it serves as a guarantee that the binary will work correctly on my system. Knowing that if something is broken, that it isn’t due to a broken build makes it easy to debug issues. For example, when I updated wlroots, and chromium broke, I was able to isolate the issue very quickly.
    - taviso 5y ago
      Can you explain the wlroots issue?
      - smasher164 5y ago
        I believe it was this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1279574 https://bugs.chromium.org/p/chromium/issues/detail?id=127957... I encountered it when I updated a bunch of NixOS packages at once. Since the crash happened in chromium, I figured I'd downgrade that specific package by pinning an older channel. It still didn't work. But I knew that chromium had worked before, and nix doesn't really use the FHS, so the system wouldn't be polluted with random versions of packages. I also knew that the SHA for chromium had to match what was here: https://github.com/NixOS/nixpkgs/commit/a1c5e5bc40749652503cd956e777455e2180b663 https://github.com/NixOS/nixpkgs/commit/a1c5e5bc40749652503c.... So if chromium wasn't the issue, the problem would have to lie elsewhere. Comparing the last two generations of my system, I found that Sway had updated, which also brought a new version of wlroots that broke older versions of chromium. I eventually found my way to this issue and rolled Sway back until the fix landed in stable. There were probably easier/quicker ways to reach the same conclusion I did. But I think that knowing the software on my system was built correctly, and was relatively isolated (i.e. wasn't depending on random versions of libraries in the FHS) made it so I wouldn't fall down a rabbit hole that lead to a dead end.
  - TacticalCoder 5y ago
    > You know without doubt that the binary that you produced was built from the source code, because you built it. > I'm asking, why not stop there? You do not know that it was built from the source code. That's precisely why you're not stopping there. For your machine, the one you're building from, may be compromised and compiling something else than the source code it's showing you (for example it may be inserting a backdoor here or there in the binary). While if you really end up with the same build as everybody else does (and you have to really make sure of that: checking the hash from the very machine you compiled from is not be sufficient), you know for sure that the build is the same everybody else ended up with.
adamzochowski 5y ago
Not OP, but this often is used when I am brought onto a new project against old code base, where no one from original developers is around. I am then given four things: - here is binary that is currently running - here is source code previous developer left - here is scant documentation of what it is supposed to accomplish - here is what we want you to change the first things you want to to do is confirm the source code you have can build the binaries running. A lot of compilers, for one reason or another, like to sprinkle random crap into the binaries that makes them different every time you compile. .Net for example adds compiled time into the binary. If you try to compare the two binaries with md5/sha they will always return different. Without reproducible builds, your next step is to run decompilers against the two binaries, and hope that that output matches. Much easier if you have reproducible builds. This is also security feature: you will know if anyone tampered with the binary.
- pabs3 5y ago
  re decompilers, with diffoscope you can do that automatically for tons of different file formats: https://diffoscope.org/ https://diffoscope.org/
- tedunangst 5y ago
  But this kinda requires going back in time to create a reproducible build system, no? Or is it common that a company goes to the trouble of creating reproducible builds and then forgets what source they used to build their binaries?

Why didn't you just build from source, and then use those binaries? What did the reproducibility add?

by taviso 5y ago

Why didn't you just build from source, and then use those binaries? What did the reproducibility add?

A verification step. Download the binary of a package as well as its source and build the source, if the resulting binary matches the hash of the other binary then you’ve just reproduced it and can consider it verified.

taviso 5y ago
You have the source, you have a binary that you've produced from that source, and you have a binary that someone else claims was produced from that source. You know without doubt that the binary that you produced was built from the source code, because you built it. I'm asking, why not stop there? You have a binary that you can safely consider "verified", what does it matter if it's bit-for-bit identical to any other binaries?
- akshayshah 5y ago
  Depends on the situation. In some cases, the old binary (that someone claims was built from the available source) is out in production doing useful things. Perhaps it’s been there for years. If it’s not built from the source you have available, you first have to figure out where the current binary came from and how to safely change it.
- smasher164 5y ago
  For me, it serves as a guarantee that the binary will work correctly on my system. Knowing that if something is broken, that it isn’t due to a broken build makes it easy to debug issues. For example, when I updated wlroots, and chromium broke, I was able to isolate the issue very quickly.
  - taviso 5y ago
    Can you explain the wlroots issue?
    - smasher164 5y ago
      I believe it was this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1279574 https://bugs.chromium.org/p/chromium/issues/detail?id=127957... I encountered it when I updated a bunch of NixOS packages at once. Since the crash happened in chromium, I figured I'd downgrade that specific package by pinning an older channel. It still didn't work. But I knew that chromium had worked before, and nix doesn't really use the FHS, so the system wouldn't be polluted with random versions of packages. I also knew that the SHA for chromium had to match what was here: https://github.com/NixOS/nixpkgs/commit/a1c5e5bc40749652503cd956e777455e2180b663 https://github.com/NixOS/nixpkgs/commit/a1c5e5bc40749652503c.... So if chromium wasn't the issue, the problem would have to lie elsewhere. Comparing the last two generations of my system, I found that Sway had updated, which also brought a new version of wlroots that broke older versions of chromium. I eventually found my way to this issue and rolled Sway back until the fix landed in stable. There were probably easier/quicker ways to reach the same conclusion I did. But I think that knowing the software on my system was built correctly, and was relatively isolated (i.e. wasn't depending on random versions of libraries in the FHS) made it so I wouldn't fall down a rabbit hole that lead to a dead end.
- TacticalCoder 5y ago
  > You know without doubt that the binary that you produced was built from the source code, because you built it. > I'm asking, why not stop there? You do not know that it was built from the source code. That's precisely why you're not stopping there. For your machine, the one you're building from, may be compromised and compiling something else than the source code it's showing you (for example it may be inserting a backdoor here or there in the binary). While if you really end up with the same build as everybody else does (and you have to really make sure of that: checking the hash from the very machine you compiled from is not be sufficient), you know for sure that the build is the same everybody else ended up with.

adamzochowski 5y ago

Not OP, but this often is used when I am brought onto a new project against old code base, where no one from original developers is around. I am then given four things: - here is binary that is currently running - here is source code previous developer left - here is scant documentation of what it is supposed to accomplish - here is what we want you to change the first things you want to to do is confirm the source code you have can build the binaries running. A lot of compilers, for one reason or another, like to sprinkle random crap into the binaries that makes them different every time you compile. .Net for example adds compiled time into the binary. If you try to compare the two binaries with md5/sha they will always return different. Without reproducible builds, your next step is to run decompilers against the two binaries, and hope that that output matches. Much easier if you have reproducible builds. This is also security feature: you will know if anyone tampered with the binary.

pabs3 5y ago
re decompilers, with diffoscope you can do that automatically for tons of different file formats: https://diffoscope.org/ https://diffoscope.org/
tedunangst 5y ago
But this kinda requires going back in time to create a reproducible build system, no? Or is it common that a company goes to the trouble of creating reproducible builds and then forgets what source they used to build their binaries?