4 ms·

> 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

> 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.

mrob 6y ago
And vendor malice isn't the only reason why the software might be harmful. What if the vendor's toolchain was compromised without their knowledge? Reproducible builds provide a means for third parties to verify that it wasn't.
- R0b0t1 6y ago
  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.
  - Foxboron 6y ago
    There has been some interesting progress with bootstrappable builds in regard to the GNU MES C compiler and building GCC. https://salsa.debian.org/reproducible-builds/reproducible-website/-/blob/master/_posts/2019-12-XX-reproducible-bootstrap-of-mes-c-compiler.md https://salsa.debian.org/reproducible-builds/reproducible-we...
  - pests 6y ago
    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.
    - Willamin 6y ago
      > 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.
      - pests 6y ago
        Well, and memory usage too etc. But what's the point then? Why would Intel have their optimizing compiler? Why GCC vs llvm?
    - R0b0t1 6y ago
      Obtaining evidence a compiler probably isn't backdoored is the point. >There's no way that every compiler would produce the same exact insrtuctions for each respected input. You don't know this.
      - pests 6y ago
        I do, because I can make a compiler that chooses non standard instructions.
        R0b0t1 6y ago
        Then nobody will use it for reproducible builds. What is your point? Performant compilers for an arch are likely to produce similar code.
    - rramdin 6y ago
      Perhaps you're comparing a multithreaded version with a single threaded version, or a single-host build vs distributed build. When adding new features to a compiler, you might want to verify that the old and new versions have the same output given the same input. If your compilers produced non-deterministic output, this exercise would not be possible.
  - a1369209993 6y ago
    > the same binary via different compilers Are you sure you aren't thinking of diverse double-compiling[0]? Which specifically does not require different compilers to produce the same output[1], just different runs of different binaries of the same compiler. 0: https://dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html https://dwheeler.com/trusting-trust/dissertation/html/wheele... 1: https://dwheeler.com/trusting-trust/#misconceptions https://dwheeler.com/trusting-trust/#misconceptions
rstuart4133 6y ago
Yes, the argument in the article seems to revolve around it is harder user to verify a build that it is to simply build it themselves. If they build it themselves there is no need to verify it of course - so what's the point of verification? You could apply that same argument to lots of things. It's hard to verify things adhere to standards in general - whether it be flammability of children's clothes, or additives in food. Bu that logic I should be making my own clothes and meals rather than relying on the manufacturers claims. Obviously, no one does. The point is someone has made a verifiable statement, in public. There is no need to go to the effort of testig that statement a zillion times. In fact needn't be done at all in many cases - just the treat of doing the test with something goes wrong suffices. In the case of food where I live, a recent recall of strawberry's devastated the industry. No one was testing if strawberry's contained needles until someone eat one, no one got seriously hurt when they did. Well no body except the strawberry industry which was on its knees for months until once again people started to take them at their word their product was safe to eat. Similarly if you care about security (and I do), if there was a choice between several several Signal like programs that all claimed verifiable builds, and then it was shown one was in fact lying about verifiability I'd drop them like a hot potato. And I wouldn't be dropping them for just months like the strawberry's, it would likely be forever. In one line: the idea that every user has to test a verifiable build does in fact verify in order for it to be useful, is seriously flawed.

mrob 6y ago

And vendor malice isn't the only reason why the software might be harmful. What if the vendor's toolchain was compromised without their knowledge? Reproducible builds provide a means for third parties to verify that it wasn't.

R0b0t1 6y ago
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.
- Foxboron 6y ago
  There has been some interesting progress with bootstrappable builds in regard to the GNU MES C compiler and building GCC. https://salsa.debian.org/reproducible-builds/reproducible-website/-/blob/master/_posts/2019-12-XX-reproducible-bootstrap-of-mes-c-compiler.md https://salsa.debian.org/reproducible-builds/reproducible-we...
- pests 6y ago
  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.
  - Willamin 6y ago
    > 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.
    - pests 6y ago
      Well, and memory usage too etc. But what's the point then? Why would Intel have their optimizing compiler? Why GCC vs llvm?
  - R0b0t1 6y ago
    Obtaining evidence a compiler probably isn't backdoored is the point. >There's no way that every compiler would produce the same exact insrtuctions for each respected input. You don't know this.
    - pests 6y ago
      I do, because I can make a compiler that chooses non standard instructions.
      - R0b0t1 6y ago
        Then nobody will use it for reproducible builds. What is your point? Performant compilers for an arch are likely to produce similar code.
  - rramdin 6y ago
    Perhaps you're comparing a multithreaded version with a single threaded version, or a single-host build vs distributed build. When adding new features to a compiler, you might want to verify that the old and new versions have the same output given the same input. If your compilers produced non-deterministic output, this exercise would not be possible.
- a1369209993 6y ago
  > the same binary via different compilers Are you sure you aren't thinking of diverse double-compiling[0]? Which specifically does not require different compilers to produce the same output[1], just different runs of different binaries of the same compiler. 0: https://dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html https://dwheeler.com/trusting-trust/dissertation/html/wheele... 1: https://dwheeler.com/trusting-trust/#misconceptions https://dwheeler.com/trusting-trust/#misconceptions

rstuart4133 6y ago

Yes, the argument in the article seems to revolve around it is harder user to verify a build that it is to simply build it themselves. If they build it themselves there is no need to verify it of course - so what's the point of verification? You could apply that same argument to lots of things. It's hard to verify things adhere to standards in general - whether it be flammability of children's clothes, or additives in food. Bu that logic I should be making my own clothes and meals rather than relying on the manufacturers claims. Obviously, no one does. The point is someone has made a verifiable statement, in public. There is no need to go to the effort of testig that statement a zillion times. In fact needn't be done at all in many cases - just the treat of doing the test with something goes wrong suffices. In the case of food where I live, a recent recall of strawberry's devastated the industry. No one was testing if strawberry's contained needles until someone eat one, no one got seriously hurt when they did. Well no body except the strawberry industry which was on its knees for months until once again people started to take them at their word their product was safe to eat. Similarly if you care about security (and I do), if there was a choice between several several Signal like programs that all claimed verifiable builds, and then it was shown one was in fact lying about verifiability I'd drop them like a hot potato. And I wouldn't be dropping them for just months like the strawberry's, it would likely be forever. In one line: the idea that every user has to test a verifiable build does in fact verify in order for it to be useful, is seriously flawed.