Distributing software is a lot harder than just building it (with the caveat that people don't want to install build dependencies). So we rely on centralized distribution (and build). Because of this we have to assume trust of that entire chain.
When builds are reproducible they are independently verifiable which means you only have to trust the code and not the entire distribution chain (build systems, storage, etc).
Of course if no one bothers to verify then it doesn't matter. This is sort of how xz happened, no one verified that the release tarballs were what they were purported to be.
I know what reproducible builds are, but they do not solve practical problems. That are actively happening.
>This is sort of how xz happened
Reproducible builds wouldn't have caught this. You would reproduce the malicous library the same since the vulnerability is in the input.
Wasn't the vulnerability triggered by a malicious script that was added silently to the tarball? Reproducible builds would have shown that the tarball is not the exact output of the build. Even though the malicious payload was already in the code, the trigger was not and was hidden
>Reproducible builds would have shown that the tarball is not the exact output of the build
That is not what reproducible builds do. Reproducible builds shows that the compiled binary comes from the inputs. You have to use the same inputs as the distro else it will most likely not match. The vulnerability is part of the input which means that anyone else reproducing the build would have a byte exact copy of the vulnerable library and no discrepancy would be found. Reproducible builds would monitor for when the builds don't match.
In this scenario you could compare release tarbells against the git repository, but that has nothing to do with reproducible builds.
Right, my point was that nobody bothered to check the source tarballs which should be completely reproducible already,