Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You don’t need reproducible builds

blog.cmpxchg8b.com

Post reply on HN
Print view View original

71–80 of 179 posts

Re: You don’t need reproducible builds

#71

Post by magnetic »

amluto wrote: post #50

There’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…

> App stores don’t currently build their apps.

On iOS (not sure about macOS apps), when you submit an app, it is submitted as "bitcode" (note, this is not "bytecode" - it's bitcode, not a typo). This allows Apple to build your app as needed from your bitcode (think of the bitcode as LLVM IR).

This is done for a couple of reasons: (a) they can take advantage of improvements in their backend compiler (IR->executable) that happens after you submit your app, (b) they can build your app on platforms that didn't exist when you submitted your app

The net result is that the App Store plays an important part in the build process, which could legitimately generate different binaries (even for the same device, see (a) above) for the same app you submit.

Re: You don’t need reproducible builds

#72

Post by wildmanx »

rocqua wrote: post #35

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

You read the original post, right? He discusses this at length. Actually, right in the beginning.

In short, if you go through the dance of building the binary yourself to compare it to what's installed, then you could just use the binary that you just built, without ever looking at what the app store has.

Re: You don’t need reproducible builds

#73

Post by arcticbull »

wildmanx wrote: post #70
arcticbull wrote: post #64

Earlier quoted context omitted.

> - If a particular version of the code is tested, and the binary is not a pure function of the code, then you haven't really tested the binary. Bugs could still be introduced that were not caught during testing because your build is non-deterministic. This is a weaker argument IMO because when building for test, generally, all optimizations are disabled, debug info is emitted, symbols are un-stripped, and so on. The…

If that's really what you are doing, then you are doing it horribly wrong.

You test prod builds?

Re: You don’t need reproducible builds

#74

Post by ISL »

wildmanx wrote: post #72
rocqua wrote: post #35

So, 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. You read the original post, right? He discusses this at length. Actually, right in the beginning. In short, if you go through the dance of building the binary yourself to…

If the app store distributes binaries to thousands of people, and only one of them rebuilds from source to check, those thousands of people gain a substantial (but not perfect) level of protection.

Re: You don’t need reproducible builds

#75

Post by aidenn0 »

wildmanx wrote: post #70
arcticbull wrote: post #64

Earlier quoted context omitted.

> - If a particular version of the code is tested, and the binary is not a pure function of the code, then you haven't really tested the binary. Bugs could still be introduced that were not caught during testing because your build is non-deterministic. This is a weaker argument IMO because when building for test, generally, all optimizations are disabled, debug info is emitted, symbols are un-stripped, and so on. The…

If that's really what you are doing, then you are doing it horribly wrong.

You do see this in embedded for several reasons, including:

- For high-volume production, reducing ROM size can have a big impact on profitability (this is less true than it was 20 years ago, but still true), so your dev boards will have large EPROMS and your production boards will have small ROMs

- Debugging tools present may allow for easier reverse-engineering of your devices

Obviously the devices go through a lot of testing in the production environment, but things like error-injection just may not exist at all, which limits how much you can test.

Re: You don’t need reproducible builds

#76

Post by mikepurvis »

Diggsey wrote: post #13

There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…

Having stable BuildIDs has been important for me in being able to sanely manage a debug symbol archive where some binaries are periodically rebuilt on different CI worker nodes.

Re: You don’t need reproducible builds

#78

Post by 7786655 »

amluto wrote: post #50

There’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…

Why can't app stores build their apps? Debian and F-Droid do.

Re: You don’t need reproducible builds

#79

Post by m463 »

magnetic wrote: post #71
amluto wrote: post #50

There’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…

> App stores don’t currently build their apps. On iOS (not sure about macOS apps), when you submit an app, it is submitted as "bitcode" (note, this is not "bytecode" - it's bitcode, not a typo). This allows Apple to build your app as needed from your bitcode (think of the bitcode as LLVM IR). This is done for a couple of reasons: (a) they can take advantage of improvements in their backend compiler (IR->executable) t…

They could also wrap your app in code that does things you didn't intend, like telemetry/metrics, interception of certain functions, etc. (Not that they couldn't do that anyway)

Re: You don’t need reproducible builds

#80

Post by joshuamorton »

Diggsey wrote: post #13

There are a lot of reasons to prefer reproducible builds, and many of them are not security related... It seems a bit presumptuous to argue that noone needs reproducible builds because one particular security argument is flawed. First, a non-flawed security argument: it only takes one non-malicious person to build a package from source and find that it doesn't match the distributed binary to spot a problem. Sure, if…

Note: This article is not talking about deterministic builds (which are a prerequisite for reproducible builds), but specifically reproducible builds.

Reproducible builds are generally speaking interesting only from a security perspective, while deterministic builds have all sorts of useful infrastructural features which the author agrees are useful.

And if you think I'm being pedantic, I'm using the official terminology from the reproducible builds site[0].

[0]: https://reproducible-builds.org/

Post reply on HN