[dvogel]

(Not OP, but...) I still fail to see the current value in confirming that a reproducing builder also included the same compromised dependency that I did when I built it. I understand that reproducible builds are guarding against dynamic attacks within build infrastructure. However I just don't see those happening. Compromised source dependencies are a 100x more common problem.

[ckastner]

I agree that compromised source dependencies are the bigger problem, but that doesn't mean a compromised build infrastructure isn't. Just this last week, we had two Linux kernel LPEs that could have been leveraged to implement just such an attack, for example.

Another thing to consider is that Debian has quite a few derivatives who may also rebuild packages from source, so you have a multiplier there.

[fsflover]

https://en.wikipedia.org/wiki/XZ_Utils_backdoor

[PunchyHamster]

that's example of attack reproducible packages do not protect from, why you are linking it ?

[fsflover]

A distro automatically verifying that installed packages are reproducible would protect the user?

[dvogel]

No, it wouldn't. The xzutils attacker compromised the source repository. The build pipeline portions were used to obscure the purpose of the exploit embedded in the source code repository.

[theteapot]

Your wrong. It was both. The payload was embedded in the binary blob test file. The mechanism to pull it into the build was added to the release tarball only.

Here's the quote from the guy that discovered it in the initial public disclosure [1]:

  After observing a few odd symptoms around liblzma (part of the xz package) on Debian sid installations over the last weeks (logins with ssh taking a lot of CPU, valgrind errors) I figured out the answer. The upstream xz repository and the xz tarballs have been backdoored. At first I thought this was a compromise of debian's package, but it turns out to be upstream. One portion of the backdoor is *solely in the distributed tarballs* and debian's import of the tarball ... it is also present in the tarballs for 5.6.0 and 5.6.1.

[1]: https://www.openwall.com/lists/oss-security/2024/03/29/4

[dvogel]

You're mistaking a compromised build pipeline versus a compromised source repo that only triggers in some build pipelines. You can do reproducible builds from compromised source tarballs. Nothing about reproducible builds necessarily requires source control. Yes, if some people who built from source control compared their builds to the builds from the tarballs it could detect the xzutils compromise. However I have yet to see a reproducible build project that includes such cross-build checks.

[theteapot]

In xz-utils hack the attacker slipped changes into the Github release tarball that were not present in the Github version / git commit history. The Debian maintainer built from the release tarball instead of just pulling from the git repo directly. Shouldn't have been doing that but good luck convincing him not to use the workflow he's been using for the last X years (I tried). With repro builds we can clone the git directly confirm we get the same build.

[mmooss]

https://news.ycombinator.com/item?id=48083768