3 ms·
Reproducible builds can improve software quality. If we believe we have a reproducible build, that's constitutes a big test case which gives us confidence in t
by kazinator 2y ago
Reproducible builds can improve software quality.
If we believe we have a reproducible build, that's constitutes a big test case which gives us confidence in the determininism of the whole software stack.
To validate that test case, we actually have to repeat the build a number of times.
If we spot a difference, something is wrong.
For instance, suppose that a compiler being used has a bug whereby it is relying on the value of an unitialized variable somewhere. That could show up as a difference in the code it generates.
Without reproducible builds, of course there are always differences in the results of a build: we cannot use repeated builds to discover that something is wrong.
(People do diffs between irreproducible builds anyway. For instance, disassemble the old and new binaries, and do a textual diff, validating that only some expected changes are present, like string literals that have embedded build dates. If you have reproducible builds, you don't have to do that kind of thing to detect a change.
Reproducible builds will strengthen the toolchains and surrounding utilities. They will flush out instabilities in build systems, like parallel Makefiles with race conditions, or indeterminate orders of object files going into a link job, etc.
- uecker 2y agoI don't think it is that unlikely that build hosts or some related part of the infrastructure gets compromised.
- tomcam 2y agoI don't know this area, but it seems to me it might be a boon to security? So that you can tell if components have been tampered with?
- bobmcnamara 2y agoBingo. We caught a virus tampering with one of our code gens this way.
- dwheeler 2y agoYes! The attack on SolarWinds Orion was an attack on its build process. A verified reproducible build would have detected the subversion, because the builds would not have matched (unless the attackers managed to detect and break into all the build processes).
- oneshtein 2y agoExact same binary can be hacked in exact same way on all platforms.
- yjftsjthsd-h 2y agoWhat?
- tomcam 2y agoIf I understand correctly that would require releasing the publisher’s private key, though，correct?
- dwheeler 2y agoOnly if you try to reproduce the signature. Usually the signature is stored separately. That way, the reproduced work's signature applies to it as well.
- dwheeler 2y agoThat would requiring breaking each of the separate build processes, which is very unlikely. This doesn't counter subverted source code, that's not what reproduciblrle builds are for.
- drewcoo 2y agofor related, see Ken Thompson: http://genius.cat-v.org/ken-thompson/texts/trusting-trust/ http://genius.cat-v.org/ken-thompson/texts/trusting-trust/
- LinuxBender 2y agoThat's already been a thing in all the Redhat variants. RPM/DNF have checksums of the installed binaries and there is GPG signing of packages and repositories. The only part of that ecosystem I've always had a gripe with is putting the GPG public keys in the mirrors. People should have to grab those from non mirrors or any low skilled attacker can just replace the keys and sign everything again. It would be caught but not right away. Changes can also be caught using bolt on tools like Tripwire, OSSEC and it's alternatives or even home grown tools that build signed manifests of approved packages usually for production approval.
- stefan_ 2y agoYou know what does not give me confidence? Updating software, but whats that, its still printing the same build date? Of course hours later tens of files deep I found out some reproducability goof just hardcoded it. So far, reproducible builds are heavy on the former, zero on these bugs you mention and zero on supply chain attacks. Some of these supposed use cases make no sense. You update the compiler. Oh no, all the code is different? Enjoy the 16h deep dive to realize someone tweaked code generation based on the cycle times given on page 7893 of the Intel x64 architecture reference manual.
- kazinator 2y agoThey should be setting the build days for a package from say the commit date of the top commit of the branch that's being built. It can't be something that doesn't change when the next version is spun. If you see a behavior like that in anybody's reproducible package system or distro, you have a valid complaint.