Beyond this, there are firmware and hardware dependencies that many manufacturers share (e.g. battery manufacturers)
Current missing components or issues:
Software:
Diverse double compilation toolchain
Fully bootstrapping
Source attacks (reproduction helps change the problem into source scanning, which LLMs might help with)
Diverse OS and environments for compilation
Firmware/hardware:
Battery firmware is commonly shared
CPUs, other controllers having malicious silicon
Motivations:
Practical improvements to the status quo
If you use a bootstrapping chain, does that solve trusting trust?
Practically, probably, but in an absolute sense probably not, because the bootstrapping chain itself is running on something untrusted
One thing to consider: a sufficiently widespread attacker (CPU backdoors) could tamper with reproducible builds to avoid non-reproducible packages from being detected; however, an attacker with that widespread foothold could just use their foothold to directly achieve their goals
Missing piece:
Reproducible builds capture and share what the necessary environment details are (buildinfo files), but they do not capture or share the diversity of the build environment in the reproducible build claim
Reproducible builds need to share a) the minimal set of things that must be the same to reproduce (deps, source epoch) and b) the actual set of things that were present (base image, firmware, CPU type, etc.).
The goal is to have maximum diversity in b) and to minimize a)
Cross-ecosystem note:
Reproducible builds in language ecosystems frequently depend on upstream dependencies that are not in your ecosystem (Android etc. depend on compilers not produced in the Android ecosystem). For most things outside Debian, trusting trust is cross-ecosystem
Particular subject of interest:
A new self-compiling language ecosystem that Debian bootstraps by uploading a binary version of the compiler, then iterating on that
Followup work:
Compile/bootstrap Debian from Guix and/or StageX to solve Debian’s cyclical dependency
Analyzing the trees of reproducibility from the current version to historical versions (“reverse bootstrapping”)
Documenting the environment that’s “providing diversity” rather than necessary for rebuilding
A trusted execution environment provides a signature over the actual environment that was used, to provide higher confidence in diversity
