Collaborative Working Sessions - Attacking and tampering with builds

Attacking and tampering with builds Notes What does tampering even look like?

Collection of possible “backstab”? attacks in 2 papers william mentioned (TODO) (One from SAP WG)

What attacks are?

Could reproducible builds have prevented xz and similar attacks?

Argument that reproducible builds can only help if your actual input can be trusted. In xz’s case, the official dist tarball was malicious to begin with.

BUT Debians current model would allow a maintainer to manipulate the inputs beforehand -> Debians developers are fully trusted anyway.

Reproducible builds can only protect against tampering with the binary artifacts, not against tampering with the input.

But it can also protect against “tampering with the build process”. Such as the build server building from a different source than it claims.

Not all projects have a consistent definition of what the canonical source of a package is (e.g. vcs repo vs dist tarball)

Debian is about to add a new gate for package migrations between unstable and testing: Checking that packages that were known to reproducible in the past are still reproducible.

Pratical problem for using reproducibility checks to raise suspicion of tampering is that there are too many packages that are not reliably reproducible in practice. That includes kernel, gcc, etc

People in the industry seem to view provenance attestation and reproducible builds as alternatives to each other. Often preferring the former as that can als help iforensics.

Short recap of the discussion, followed by a short reminder of the original goal: ensuring that tampering with the build env in various way would actually sound an alarm.

One possible approach would be tooling to set up a copy of (Debians) build infrastructure with “fault injection”. Discussion about how rebuilderd might be able to do this.

Recap: