Gothenburg 2026 - Day 3 - Enforcement, part 2

Follow-up of a session on day 2

• Distro policy, where reproducible builds block updating packages
  • People can bypass this by asking for things to
• Client side enforcement
• Where can we put enforcement? How do we move information around?
• Meta-enforcement, EU?, software that offers public services should be open source and build reproducibly
• There’s a German startup which helps with reproducible docker images (Zendis, L3monTree, devguard.org)
• State in Arch at the moment, 70% at the moment is reproducible, so enforcing client side would break installs
• Fallback building from source
• People don’t care about reproducibility, they care about trust
• Profile guided optimisation is still an issue, but distros already target a broad range of hardware support over speed
• Focusing on the client side experience is good, then you can work backwards to inform other things
• What do you expect to happen if some core package is non-reproducibe?
  • One idea, some kind of poilcy, with exceptions to handle this case
  • Users might need software that doesn’t build reproduucibly, so they might feel that they don’t have a choice
• There’s a need to handle this on a ongoing basis, since reproducibility issues will still crop up in the future
• There’s some benefits already from reproducible builds, e.g. small fixes don’t have uninteded consequences
• Maybe a downside with client side verification can lead you with an inconsistent repo state
  • You could have a setup where non-reproducible packages are held back, rather than being shown to clients but not being installable
• What are the unsolved problems with the space, on both the client and server side?
  • How should users see this, if at all, how should failures be surfaced?
  • On a distro level, many distributions don’t have a policy on reproducible builds
  • Lack of tooling on the client side
  • Protocol definitions, e.g. rebuilderd interoperating with oss-rebuild
  • Should clients connect out to find signatures from the different sources they trust, or should these be batched up?
  • Can transparency logs be used?
  • Handling the remaining 1% non-reproducible things.
• Path forward with profile guided optimisation?
  • In Debian, maybe two paths forward, accept some non-reproducible packages, fix the non-reproducibility
• For source based distros, Guix, Nixpkgs, Gentoo, … some of these problems are easier to get around, since you can fall back to building from source
• TLS is a helpful model here.
• Practical issues on verifying reproduuucibility
  • Verifiers go down
• Is it enough to claim that all a distro’s packages are reproducible?
• How do things work for 3rd party repositories?
• Policy on a package level?
  • Exceptions on a package level
• APT implementation details
• Easy sketch
• How does this work for airgaped environments?