4 ms·
Practically speaking, the idea with a reproducible build is that you can take the source files they used, run their instructions the same way they did and get h
by noirscape 2y ago
Practically speaking, the idea with a reproducible build is that you can take the source files they used, run their instructions the same way they did and get hash for hash[0] the specific resulting executable.
The main benefit is that you can trust that the resulting binary file being served matches the source code that it's build from. This mostly matters for distros in that they build from a source package repository, but anyone running a mirror could hypothetically replace the package with another (potentially malicious) package, leading users to install malicious tooling. It mainly matters for distros because pretty much every distro out there runs on third party mirrors (often ran by universities, but also just people who want to help) rather than on direct upstream; packages get uploaded to a main server, then mirrors copy from that main server (to reduce network traffic load on the main server). Right now, mirror trust is mostly "we assume you're not gonna be evil, until we get complaints". If the build is reproducible, the software can inherently confirm that the file they're getting is trustworthy, making "getting complaints" much easier to confirm.
It can also speed up the overall building process; if the package source code hasn't changed, you can also always assume that the resulting binary hasn't changed (meaning you can use hashes instead of relying on mtime like make does). Docker build cache works in a somewhat similar way (although docker isn't inherently deterministic).
Devwise, you can also reconstruct a build much easier if it's reproducible; ie. if you've accidentally thrown away the .elf file for debugging, if your build is deterministic, you can just rerun the build and get the same .elf file again.
[0]: While not a problem for Linux distros, in cases where you need a secret to sign an application, reproducible typically means "identical except for the signature" instead. F-Droid uses this for example to figure out if they should use buildserver stuff or the original APKs: https://f-droid.org/docs/Reproducible_Builds/ https://f-droid.org/docs/Reproducible_Builds/
- yellow_lead 2y ago> a mirror could hypothetically replace the package with another (potentially malicious) package, leading users to install malicious tooling. It was my assumption that a mirror is required to host a build that has a hash conforming to the original. Is that not the case?
- gruez 2y agoMore specifically the packages are signed by the distro and automatically checked, so a mirror can't go rogue even if it wanted to.
- jerf 2y agoYes, the real attack isn't that mirrors change the files, the real attack is that just because a distro packages Binary X and Source X, it is difficult without reproducible builds to prove that Source X actually did produce Binary X. It could have been compiled with a trojan in it between the source and binary.
- deleted 2y ago[deleted]
- SkiFire13 2y ago> meaning you can use hashes instead of relying on mtime like make does Note that mtime still has the advantage of being faster than hashing.
- deleted 2y ago[deleted]
- patmorgan23 2y ago>but anyone running a mirror could hypothetically replace the package with another (potentially malicious) package, leading users to install malicious tooling. I thought all packages were cryptographically signed, and that the package manager would compare the hashes of artifacts downloaded from mirrors to the hashes listed in the package index (which is also signed). This is not an attack that needs reproducible builds to mitigate.