I have not stopped. I really should stop. At this point it's just kind of fun, but I have an unbroken chain of self-compiled Go compilers going back to the days when Go was written in C and not Go.
I am frankly really curious if my Go binary lives up to the reproducible build, or if some sort of Reflections on Trusting Trust type flaw worked itself in 10 years ago.
GauntletWizard•3mo ago
charcircuit•3mo ago
anilgulecha•3mo ago
charcircuit•3mo ago
cpuguy83•3mo ago
charcircuit•3mo ago
>without reproducible build you can't independently verify anything.
This is myth propagated by reproducible builds people. Byte for byte similarity is not required to detect a Trojan was injected into one.
cpuguy83•3mo ago
cpuguy83•3mo ago
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.
charcircuit•3mo ago
>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.
cpuguy83•3mo ago
Orygin•3mo ago
charcircuit•3mo ago
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.
Orygin•3mo ago
In case of XZ, the source code was modified, in the install script and not in the binary itself. Checking against a reproducible tarball would have shown the package is not identical, as the trigger was put manually by the maintainer and not checked in the repo. If you had a "byte exact copy" of the repository, it would show immediately it's not the same used to build the package.
Otherwise, reproducible builds are useless if you only check for the binary and not the whole generated package, as XZ has shown, because the malicious code could be somewhere else than the binary.
Nix packages seem to be geared toward reproducible builds of the whole package and not just the binary. So it seems possible to do.