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

131–140 of 179 posts

Re: You don’t need reproducible builds

#131

Post by renox »

biddlesby wrote: post #119
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…

Completely agree! The article is blinkered to the security aspect. But imagine if compilers didn't create reproducible builds. Debugging would be a nightmare!

Uh? Is that sarcasm? Compilers don't produce reproducible builds. If you try to investigate a core dump using a binary recompiled from sources instead of the original binary, it's very likely you won't be able to analyze the core..

Re: You don’t need reproducible builds

#132

Post by [deleted] »

arcticbull wrote: post #64
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…

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

[deleted]

Re: You don’t need reproducible builds

#133

Post by barkingcat »

arcticbull wrote: post #86
joshuamorton wrote: post #85

Earlier quoted context omitted.

As part of the release process, yes...absolutely. Compared to basically every other part of release qualification (manual QA, canarying, etc.) re-testing on the prod build is so unbelievably cheap there's no reason to not.

I suppose we're referring to different kinds of testing. Manual QA, etc, on prod sure. But if you're building client software artifacts, to unit test or integration test involves building different software in a different configuration, with different software and running it in a test harness. To facilitate unit testing or integration testing client software you: - Build with a lower optimization level (-O0 usually)…

That's called a debug build.

Not a test.

Re: You don’t need reproducible builds

#134

Post by timwaagh »

i think mostly we want to be as reproducible as possible is because a non reproducible build means there might be new bugs in it that werent there previously (when using the same source). for example a dependency might have been updated and might now be incompatible. it happens. its not malicious, but its annoying. this usually gives a lot of 'works on my machine' discussion, which is a rather frustrating and unhelpful situation.

Re: You don’t need reproducible builds

#135

Post by saagarjha »

oefrha wrote: post #55
filleokus wrote: post #49

Earlier quoted context omitted.

> 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. At least on iOS it would be very hard to get a hash of the binary running on your phone, not possible without jailbreaking AFAIK? You could check it on your computer of cou…

> You could check it on your computer of course App Store-distributed ipas can’t be decrypted without keys burned into iOS hardware, so you can’t decrypt them on a Mac without a jailbroken iOS device. (You can hash the encrypted binary but of course that’s pretty useless for reproducibility.) This might be about to change since Apple has announced support for running iOS apps directly on Apple Silicon Macs?

The Apple Silicon Macs probably have the exact same hardware, but you don’t have to really “jailbreak” then I guess…

Re: You don’t need reproducible builds

#136

Post by saagarjha »

amluto wrote: post #58
thinkmassive wrote: post #57

Earlier quoted context omitted.

This is such an underrated improvement app stores could make, which would make a large impact for minimal effort. They already require signed binary submissions, just publish the hash so we can verify it! Edit: it's a large impact for the tiny fraction of the population who's interested in verification, with no degradation of the experience for everyone else

It could be bigger than that. Imagine a little badge for open-source apps that don’t use any closed-source SDKs. These apps could be prioritized in search, and the users would benefit: less garbage in simple apps and higher battery life. This won’t directly drive income for the app store in question, but it may drive perceived value of the platform as a whole.

This is the kind of thing that only Hacker News users would care about.

Re: You don’t need reproducible builds

#137

Post by withinboredom »

joshuamorton wrote: post #88
arcticbull wrote: post #86

Earlier quoted context omitted.

I suppose we're referring to different kinds of testing. Manual QA, etc, on prod sure. But if you're building client software artifacts, to unit test or integration test involves building different software in a different configuration, with different software and running it in a test harness. To facilitate unit testing or integration testing client software you: - Build with a lower optimization level (-O0 usually)…

No, I'm saying you re-run your automated unit tests on the release build because there's no reason not to. If you have test failures in opt/stripped mode, they're more annoying to debug yes, but wouldn't you want to know? Another way of putting this is that when you > - Build and link your tests code into a library artifact. You build and link the same object files that will be built into the release binary artifact,…

> I, uhh, usually do this in my released software too.

Do you have any idea how annoying it is to get logged garbage when starting something on the command line (looking at you IntelliJ)?

I once spent several weeks hunting through Hadoop stack traces for a null pointer exception that was being thrown in a log function. If the logging wasn’t being done in production, I wouldn’t have wasted my life and could have been doing useful things. Sadly, shutting down the cluster to patch it wasn’t an option, so I had to work around it by calling something unrelated to ensure the variable wasn’t null when it did log.

Re: You don’t need reproducible builds

#138

Post by benibela »

I would already be happy with working builds

If you use a non-mainstream compiler it is a horrible mess. Almost every other time I build my program, the compiler crashes and I have to make a clean build.

Recently they have fixed the issue, I updated the compiler, and now it still does not compile. Random type checking error. After a clean build, the type is accepted and it compiles. I tried to make a mwe, and instead of a type checking error, the the compiler crashes at that line.

At least it always compiles with a clean build. But the resulting program does not start (not accepted load segments). I have not figured that one out, so I uninstalled the update and keep using the crashing compiler version.

Re: You don’t need reproducible builds

#139

Post by pests »

R0b0t1 wrote: post #99
mrob wrote: post #25

Earlier quoted context omitted.

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.

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.

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.

Re: You don’t need reproducible builds

#140

Post by TwoBit »

renox wrote: post #131
biddlesby wrote: post #119

Earlier quoted context omitted.

Completely agree! The article is blinkered to the security aspect. But imagine if compilers didn't create reproducible builds. Debugging would be a nightmare!

Uh? Is that sarcasm? Compilers don't produce reproducible builds. If you try to investigate a core dump using a binary recompiled from sources instead of the original binary, it's very likely you won't be able to analyze the core..

Since when don't compilers produce reproducible builds? We did that at my last workplace with appropriate MSVC compiler options.

In any case, maybe parent is referring to using centralized debug symbols which can work for anybody in the org because their compilers all generate the same output.

Post reply on HN