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

31–40 of 179 posts

Re: You don’t need reproducible builds

#31

Post by cesaref »

Semaphor wrote: post #6
mainguy wrote: post #4

I think OP is coming from a different perspective than I (corporate bespoke solution builder) do. When I say "reproducible build" I mean a build that is the same on any machine (i.e. no special magic necessary to build a "official" version of the code). Too often in corporate environments, getting a local build or setting up a new build pipeline involves arcane black magic and/or copy/pasting weird libraries that can…

It’s a well-defined term though https://en.wikipedia.org/wiki/Reproducible_builds

Well I think that's the crux of the issue, i've been using the term reproducible build to mean something different for the last 25 years. I'm after functional equivalence not binary equivalence. Now it might be impossible to guarantee one without the other, but that's all I care about.

Re: You don’t need reproducible builds

#33

Post by ta8594505930 »

ENOTTY wrote: post #24
chii wrote: post #22

Earlier quoted context omitted.

but this just shifts the burden of who to trust to the verifiers. It didn't make the software from the vendor _any more_ trustworthy.

> this just shifts the burden of who to trust to the verifiers Agreed. A colleague once said that trust is like a balloon; if you reduce trust in one area, you tend to expand trust in another area. I think the typical response to your statement from a user is that it’s easier to trust a set of verifiers than it is to trust a vendor. The act of a verifier blessing an artifact makes that artifact more trustworthy. Pers…

Presumably there is benefit in reducing trust in a party with mixed or unknown incentives to increase trust in a party whose incentives align with your own. For a critical piece of software I could imagine a schema where a user pays one or more independent verifiers to validate the software. That would allow the user to control the incentives of the entities telling them the software is safe.

Re: You don’t need reproducible builds

#35

Post by rocqua »

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 package I want from source (otherwise I'd run gentoo). Requires so much more dependency hell I'd rather avoid. With reproducible builds, I can check the source for any package, and so can every other curious person. This way, instead of everyone needing to set up their own build environment for every package, we can all depend that once in a while, someone checks whether a build actually comes from trusted source code.

Is it less secure than building myself? YES. Does it make deploying compromised code more likely to be detected than without reproducible builds? Also yes!

Heck, if we change from "depend that once in a while, someone checks whether a build actually comes from trusted source code." To a federated system of trusted checkers. It gives pretty nice guarantees, and makes depolying compromised code pretty damn scary.

Essentially. Whenever the person compiling / signing the binary is not the person writing the source code, reproducible builds are pretty dang nice.

Re: You don’t need reproducible builds

#36

Post by Znafon »

olafure wrote: post #20

Here's a hypothetical but a realistic scenario that not having reproducible builds is a major issue: 1. I create an app for a client. 2. Client installs the app on their 10,000 enterprise mobile devices and trains the users. 3. Month passes. I've changed everything in the app. 4. Major security or outage event happens. I need to change a line in the app and those 10,000 devices need to be updated ASAP. 5. If I can't…

You would still have to do it with reproducible builds. It's only reproducible if you have the same code. If you change something there is no reasons to get the same result, a bit like you would expect with a hash, it is deterministic, but that's all.

Re: You don’t need reproducible builds

#37

Post by filleokus »

cesaref wrote: post #28
mrich wrote: post #23

Earlier quoted context omitted.

You are making the case for source control and having no external dependencies like npm, but you don't need reproducible builds for that.

I've a feeling there's multiple definitions of build reproducibility going on here. I'm guessing you mean that it's not important to be have something byte for byte identical, but more to ensure that exactly the same build steps were run with the same source code? For most of us, that's what build reproducibility means, but I guess for a subset of users it means producing an identical binary.

> but I guess for a subset of users it means producing an identical binary.

Whenever I hear people talk about the problems of creating reproducible builds, I often hear stuff about timestamps or other metadata inserted by the compiler that would "break" the reproducibility (under the stricter definition).

Having your own source code versioned and dependencies version-pinned (and pretty high confidence that the dependency package foobar-1.12 stays the same over time) seem just like old fashioned "good practice".

The looser definition would imply that all versioned software without external dependencies (or the source of the dependencies manually included in the repository) is reproducible?

Re: You don’t need reproducible builds

#38

Post by weinzierl »

For me security is not the only thing that make reproducible builds interesting. I'm often interested to link a binary to its source in retrospect. This is at a time when the vendor might long be gone. It helps a lot to be reasonably sure that the source you analyze is the one that was used to build the binary and you don't waste time studying the wrong source.

The counterargument is, of course, that if you are serious you should look at the binary anyway and never trust the source, and I can't argue with that, except - for better or worse - that this is not the world I live in. For me an as short as possible time to answer a question about a software with as much confidence as possible is key. I'm alway grateful when I can reproduce the build with reasonable effort and then look at the source instead of the binary. Regardless how much I love to tinker with binaries, looking at the source is usually just faster.

Re: You don’t need reproducible builds

#39

Post by moomin »

You know that principle that mathematicians invoke when someone "proves" P=NP? i.e. do they mention any of the classic problems in the space? Well, if you can't find the word "Debian" in an article on reproducible builds you can be reasonably guaranteed it's missed something.

Re: You don’t need reproducible builds

#40

Post by vmchale »

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…

Yes, CI is the big one for me.
Post reply on HN