Arguing about source inputs (Was: Irregular status update about reproducible Debian live ISO images)

[David A. Wheeler]

> On Mar 28, 2025, at 2:59 PM, Matthew Suozzo via rb-general <rb-general at lists.reproducible-builds.org> wrote:
> Since this is posted on a list that is mostly used for supply-chain 
> security discussion, I think it's unfortunate how blobs are singled out 
> as "this build input is difficult to review because it's not human 
> readable", yet xz has shown we aren't really reviewing human readable 
> build inputs either (or at least we aren't successful and too easily 
> clowned by our own tools).
> 
> Might be worth highlighting that the xz exploit payload was embedded in a checked-in binary blob (test file). Not sure I'd consider those "human readable" inputs.

The *trigger* for the xz exploit payload was *NEVER* checked in to the version control repository.
Most of the payload was in a binary blob, but it didn't do anything until a trigger was added.

Normally reviewers download source code from the repository
(e.g., the main/master/current/tip version). Unfortunately, the "source"
tarball wasn't a copy of the version control's latest version, it was
an auto-generated version with a malicious trigger added.
We need to make sure that what's under version control & reviewed is what's used.

Based on the xz experience, the OpenSSF
"Concise Guide for Developing More Secure Software"
<https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software>
added the following point:
"If a source code (unbuilt) package is released, it should only include content from the version control system (VCS), and source package users should rebuild, if needed, to create production (built) package(s). E.g., if autotools is used, if a source package is released it should not include a generated configure file, while recipients should ignore pre-generated files like configure and instead rebuild from source (e.g., with autoreconf). This eliminates a malware-hiding mechanism, as illustrated by an attack on xz utils."

> (I obviously still believe connecting binaries to source code with 
> reproducible builds as much as possible is useful).

Yes. Each package that's a verified reproducible build creates another
barrier for attackers.

--- David A. Wheeler