41–50 of 179 posts
Interesting off topic point about the lack of accountability in the profession. Even as a sysadmin, one accidental iptables flag might let an intruder gain access. What will happen to me? Angry boss maybe.
Earlier quoted context omitted.
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 depend…
Also, how many people run the build in a sandbox to avoid "interference" from the environment?
Yes, this is all good practice, but I think very few people do it, because it's not easy.
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…
Thus:
> You don’t need reproducible builds
No, not for open source. If it's open source, it's only valuable and useful to have the source code if I can build it. Otherwise, if I can't build it, to me it's no different than closed source.
> You don’t need reproducible builds
In a commercial development environment I need to build the code I work on. What about when a bug exists due to problems in the build environment? If I can't reproduce the build environment, I can't fix the bug.
And then there's a QA which answers criticism with "I absolutely disagree", "I think this is true, but".
> We know that attackers really do want to compromise build infrastructure, but more often they want to steal proprietary source code, which must pass through build servers.
This has shifted the goalposts so much they're on a different field now.
Earlier quoted context omitted.
> 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 depend…
How many people pin the exact version of a system library they are using? Or of a binary used in the build process. Also, how many people run the build in a sandbox to avoid "interference" from the environment? Yes, this is all good practice, but I think very few people do it, because it's not easy.
But further: All of these things would still not be enough for the strictest definition (exact same binary), at least with normal compiler defaults afaik?
Earlier quoted context omitted.
> 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 depend…
How many people pin the exact version of a system library they are using? Or of a binary used in the build process. Also, how many people run the build in a sandbox to avoid "interference" from the environment? Yes, this is all good practice, but I think very few people do it, because it's not easy.
Linux distributions does. Both Debian and Arch Linux embed information about the entire build environment into the built package.
> Also, how many people run the build in a sandbox to avoid "interference" from the environment?
Most linux distributions does this.
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…
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 course, but what's stopping $vendor from having an device.id == rocqua's phone check when they deliver the binary to your phone? Further, doesn't (at least) Apple do something with the signatures causing the binary downloaded to actually be slightly different and missmatch the one uploaded by the developer?
If you don't trust your OS and in extension (at least on very locked down platforms as iOS) your OS vendor, it's basically game over. I mean, they have root on your connected device and could easily change what binary is started, even if you could verify the copy you downloaded onto disk.
App stores could improve the situation by building apps themselves, but I think that would put them in an position they don’t like. App stores don’t currently build their apps.
With reproducible builds, app stores could do better. An app store could list the hash of the build artifacts along with the purported name and developer, allowing various degrees of assurance that an app is actually a build of the source it supposedly comes from. Without reproducible builds, the app store would have to build the app itself and use its build instead in the submitted build, which seems undesirable.
Tavis’s argument about bugdoors still applies, but IMO it’s largely irrelevant to the major app threat model. Many useful apps don’t have input and output that is susceptible to corrupt data. A lot shouldn’t access the network at all. The common threat is that they include fifteen tracker SDKs, all of which are malicious by design. Including the entire Facebook SDK is going to be tricky as a bugdoor.