Gothenburg 2026 - Day 2 - Security and Reproducible Builds

Security and RB

• Should we distinguish between using reproducibility to detect non-malicious vulnerabilities vs. malicious activity?
  • Are we using this proactively or reactively?
  • Are we trying to prevent bad behavior, or just log it for others?

• Two related but different aspects: reducing implict trust in build pipelines, and distributing trust assumptions amongst different parties to reduce vulnerability against malicious actors.

• A big problem - reproducibility is source + build environment. What can we do to pin/communicate the build context?
  • system transparency
  • hardware trust protocols / 2-phase signing - only sign hardware-signed builds
  • N of M quorums amongst independent build servers
• Another big problem - how to establish/maintain trust?
  • how do we get rebuilders?
  • how many do we actually need?
  • what do to bad rebuilders, both accidentally bad (unreliable) or intentionally bad (i.e. sybil attack)
  • how do we deal with the evolution of policies over time, i.e. expand/reduce quorum out of necessity?
• Trust all the way down
  • 4 “layers” - developer, software, hardware operator, hardware itself
  • Pushing risk out of software and into hardware is still a practical risk reduction
• What to do when reproducibility fails?
  • what “level” of reproducibility do we care about?
  • is every reproducibility failure worth reporting?
  • should we look for “middle ground” policies between binary allow/reject decision for non-reproducible software?