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

111–120 of 179 posts

Re: You don’t need reproducible builds

#111

Post by hinkley »

hinkley wrote: post #102
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…

Scientific method debugging as well. If the new version is busted, I want to rebuild the same output only changing the compiler, or package manager, or one of the library upgrades, and see what happens. If I can't reproduce last tuesday then how do I get back to Friday when shit wasn't on fire?

This also goes the other way too. Repeatability is daylight that removes our ability to delude ourselves that a new problem must be someone else's code.

I don't want to police my coworkers. I just want to know that the infrastructure will hold my proverbial weight when I step on it, so I don't have to be afraid of side effects all day.

I want to know what I can trust them to do, and work to expand that envelope. If people break stuff, I eventually want them to be able to figure it out, reproduce it, and fix it all under their own steam, and [believe] that it's the right thing to do.

My automation strategy is a superset of a list I'm sure you've all heard already:

Make it documented

Make it work (automated)

Make it right (trustworthy)

Make it recommended

Make it easy (may include fast)

Make it mandatory

Make it an HR problem

About the time the tool is starting to get easy, you can start teasing people for not using it, but at some point it's expected behavior. More peer pressure from more sources. If they still like to cowboy, that speaks to trust, and they start getting delisted from new initiatives. If that still doesn't work (which, sadly, occasionally is the case), they are compartmentalized and shortlisted for the next reorg or layoff.

Re: You don’t need reproducible builds

#112

Post by Ericson2314 »

GauntletWizard wrote: post #106
joshuamorton wrote: post #80

Earlier quoted context omitted.

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

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…

What is the difference?

Re: You don’t need reproducible builds

#113

Post by strbean »

chii wrote: post #22
ENOTTY wrote: post #21

I think the author hasn’t accurately described the workflow where reproducible builds are used. Here’s my attempt. There are three entities: 1. The vendor, who creates and _distributes_ a product, which may include software, to the end user 2. The end user, who receives the product from the vendor, operates the product, and trusts one or more verifiers to correctly certify the product according to some standard that…

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.

It shifts and distributes the burden of trust. There are mountains of scenarios where we shift from "we rely on trusting this one person / entity" to "we rely on trusting at least one of these N people / entities", and that is a huge win every time.

Re: You don’t need reproducible builds

#114

Post by Ericson2314 »

The post started out OK, but then I lost the plot

> Q. It’s easier to tamper with binaries than to write a bugdoor, so reproducible builds do improve security. > > I absolutely disagree, every programmer knows how to write a bug or short circuit some logic. Hiding malicious activity in a binary, with a multi billion dollar malware industry determined to find it is more difficult. In addition, once you’ve produced and signed the malicious backdoor, it is not repudiable - you can’t deny you wrote and provided it. > > With bugdoors, you don’t need to deny it - you just claim it was an error, and you’re automatically forgiven.

If the binary vendor has the source code, every source exploit is also a binary exploit. If you can make a semi-"bugdoor" that's plausibly deniable, and then augment it with a binary tamper that's deniable as an artifact of non-deterministic compilation, is that not the ultimate coup de grâce?

Re: You don’t need reproducible builds

#115

Post by NovemberWhiskey »

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…

This is exactly right. Having the build process be 'reproducible' i.e. deterministic means it is insulated from mysterious action-at-a-distance mechanisms that break things I want or need to be invariant within my CI/CD process.

Re: You don’t need reproducible builds

#116

Post by hinkley »

richardwhiuk wrote: post #94
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…

Agree. In critical infrastructure, it's often essential to provide customers with a single fix. If you can't reproduce the build that they have, then you can't do that.

We have an internal tool that grovels through dependencies looking for first party code, and then pulls that thread all the way to hyperlinks to the ticket numbers and the commit diffs.

So not only can we build another copy with the same third party code, when we do a bug fix you can validate that you in fact only got that one change into the bugfix.

Even with infrastructure to do surgery on dependencies, it's quite possible to fat finger something and get too much or not enough. So we built a sanity tool that gives the engineering sign-off prior to validation a bit of gravitas.

Re: You don’t need reproducible builds

#117

Post by Foxboron »

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.

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

Re: You don’t need reproducible builds

#118

Post by j88439h84 »

rmrfrmrf wrote: post #107

If you're looking for an actual spicy take, you could say that reproducible builds are impossible once the durability of hardware/state of the universe is accounted for, but that the concept provides yet another black hole of cash and effort with which devsec can build a cottage industry around.

There is a trusted hardware industry emerging, so your story has plausibility

Re: You don’t need reproducible builds

#119

Post by biddlesby »

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!

Re: You don’t need reproducible builds

#120

Post by neurostimulant »

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.

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 they see fit (e.g. to optimize for each user's device arch, etc).

Post reply on HN