I suggest writing a longer paper on "why reproducible builds" and posting it on the r-b website. Here are few quick points from me that might be helpful.
In general, we should focus on risk.. but not just current risk, but future risk. It's absolutely *true* that unintentional vulnerabilities in source code are *far* more common. There *are* efforts to counter them & reduce them over time. These also counter "bugdoors"; if a vulnerability is in source, a tool or human reviewer has an opportunity to detect them. If unintentional vulnerabilities aren't addressed, then reproducible builds won't help, and if that's their argument I strongly *agree*. I'm operating under the assumption that over the next few years we're finally going to serious focus on eliminating vulnerabilities in source code. For example, by actually training software developers in how to develop secure software (something we don't currently do), adding tools to detect vulnerabilities, & modifying infrastructure to make vulnerabilities less likely (both in source code and in the supply chain). Asking everyone to recompile source code is *not* a reasonable strategy. Yes, some people will do it, but almost no one does, and that will not change. We need a mechanism that can detect subverted builds *without* requiring everyone to recompile their local copies of software. Reproducible builds does that. It's true that attacks on builds and compilers are rare, but that doesn't mean they'll stay that way. SolarWinds had a subverted build process. And we've already seen a subverted compiler in action. In 2015 it was revealed that over 4,000 Apple iOS applications were subverted and got into the Apple app store through an attack called XCodeGhost. This attack convinced developers to use a subverted version of Apple's XCode development environment. Many popular applications were infected via XCodeGhost, including Angry Birds 2 and WeChat. FireEye estimated that XcodeGhost added malicious code to over 4000 apps. Reproducible builds by themselves counter subverted builds. If you want to counter the trusting trust attack, you need an additional technique, either diverse double-compiling (DDC, the subject of my PhD dissertation) or bootstrappable builds. But that's okay, these are reasonable additions after you have reproducible builds & are worrying about subversion of the underlying build tools (instead of primary build process). As far as hardware subversion goes, obviously that's a different challenge. However, such subversions (especially if they aren't just DoS) are more challenging. Chips are made in factories where there have to be a lot of controls to start with, so while there *are* ways to subvert them, there are also countermeasures. The "simple" solution is to source parts from sources more likely to be trustworthy. Remember, the goal is not to eliminate all possible risk - that is impractical. Instead, the goal is to reduce risks to acceptable levels. We can do a *lot* today to reduce those risks. Today, what's under attack is the software... so let's do our part to counter those attacks. --- David A. Wheeler
