Live data from Hacker News

You don’t need reproducible builds

blog.cmpxchg8b.com

161–170 of 179 posts

Re: You don’t need reproducible builds

#161

Ugh... If building the same source produces different binaries, then I'd like to know (a) what is causing the difference and (b) what other differences does it cause? Being able to produce a consistent result is simply a sign of professionalism.

In Java for example you this might happen from generated classes in my case JAXB classes generated from xsd.

In in javascript minimizers are not deterministic leading to different .js files.

Running into this has nothing to do with professionalism.

Re: You don’t need reproducible builds

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

You read my post aswell right? I don't want to check the binary myself. I want others to have that opportunity, so that tampering would be detected.

I am lazy, reproducible builds let the diligent protect the lazy.

Re: You don’t need reproducible builds

#163
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. Isn't this already happening on both play store and app store? The actual package delivered to end users is actually generated and signed by google/apple, and they can modify the binary inside the package as…

If Google shows their modifications, it could still be checked against the source code.

Re: You don’t need reproducible builds

#164
post #131

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

>it's very likely you won't be able to analyze the core..

You know that's the reproducible part, exact same library's same compiler same options.

>Compilers don't produce reproducible builds.

Sure they do, just compile two times the same and compare its hash, would be terrible if compilers makes something else every-time.

Re: You don’t need reproducible builds

#165
post #164
post #131

Earlier quoted context omitted.

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

>it's very likely you won't be able to analyze the core.. You know that's the reproducible part, exact same library's same compiler same options. >Compilers don't produce reproducible builds. Sure they do, just compile two times the same and compare its hash, would be terrible if compilers makes something else every-time.

By default you're not guaranteed the exact same output in two compiled binaries. There's a lot of variable bits[1] that make into binaries from C and C++. Different languages/compilers have different levels of variable bits.

[1] https://blog.conan.io/2019/09/02/Deterministic-builds-with-C...

Re: You don’t need reproducible builds

#166
post #139
post #99

Earlier quoted context omitted.

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.

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.

Re: You don’t need reproducible builds

#167

Hi Travis, If you are reading this, I'm one of the members of the TUF [1] and in-toto [2] team, where we try to solve exactly this kind of problems. While I agree with you that reproducible builds sound a lot simpler than they actually are to achieve (and leaving aside all the practical complexities you mentioned in the blog post), I think they provide value for a certain use case seemingly not mentioned in the blog…

I think it's "Tavis" (no "r")

my bad, but still, no reply as yet...

Re: You don’t need reproducible builds

#168
post #164

Earlier quoted context omitted.

>it's very likely you won't be able to analyze the core.. You know that's the reproducible part, exact same library's same compiler same options. >Compilers don't produce reproducible builds. Sure they do, just compile two times the same and compare its hash, would be terrible if compilers makes something else every-time.

By default you're not guaranteed the exact same output in two compiled binaries. There's a lot of variable bits[1] that make into binaries from C and C++. Different languages/compilers have different levels of variable bits. [1] https://blog.conan.io/2019/09/02/Deterministic-builds-with-C...

>Different languages/compilers have different levels of variable bits.

No that's the point! Exact same environment same binary, that's reproducibility.

Re: You don’t need reproducible builds

#169
Reproducable builds keep honest vendors honest. If I introduce reproducable builds, I make it likelier to get caught if I tamper with my own binaries. Likewise if I provide checksums for my downloads.

There are a lot of popular freeware and open source projects from small teams or individuals. You can't tell me that no one is at least a little bit tempted to slip in a trojan occasionally.

Re: You don’t need reproducible builds

#170

Earlier quoted context omitted.

You're semantically right, but also missing the point. The expense of getting to deterministic builds is large - You have to take great care in your build infrastructure and scripts. The benefits are also large, and worth it. Once you've gotten to deterministic builds, the expense of getting to reproducible builds is small; Typically days worth of work as opposed to months. The benefits are very different, but far fr…

It really depends. If I’m building a Java project, I’m pretty sure I’ve got a deterministic build just by running javac pointed at a source directory. If I want a reproducible build, I probably need to do a lot more: - ensure timestamps of all files embedded in jar files is consistent - ensure there is no BuildTime/BuildHost/BuildNumber variable of any kind being captured - ensure the exact version of compiler is doc…

Like the GP says, I can't imagine that would take more than a few days, even for a very large project with many dependencies.
Post reply on HN