4 ms·

Is reproducability achiveable? If you preserved an immutable tag of the source code and all its dependencies, a copy of the compiler version used and all build

Is reproducability achiveable? If you preserved an immutable tag of the source code and all its dependencies, a copy of the compiler version used and all build flags, then you’ve still got some big holes in your ability to reproduce a binary: 1. OS version & patches installed 2. OS configuration 3. Hardware used (processors can have weird subtle bugs, microcode can affect execution behaviour, etc etc) 4. Transient issues - the golden copy to be reproduced for some post event investigation might have contained a bit flip leading to impossible to reproduce verification signatures Etc etc Or is reproducability just a spectrum and you try to get further along it with some careful attention to detail, rather than an absolute to be achieved? If the latter are you not cheaper just archiving binaries and tagging them with the source + deps + compiler + arch used to build them? Thats a 5 minute job to setup in your CI process and costs comparatively little to maintain vs wasting expensive human brains chasing down a futile goal.

IshKebab 5y ago
Reproducibility is absolutely achievable. It is difficult with languages that have C system dependencies like C and Rust though. Usually you have to effectively check the compiler and system headers into your repo, which isn't ideal. For something like Go it's trivial though. If you're using pure Go code then reproducible builds are pretty much as simple as "compile using Go 1.xx". I don't understand why you think 3. and 4. are issues. Bit flips are very unlikely at compilation scale, and the hardware you use to compile something shouldn't affect the output. In either case you can just compile it twice and on different hardware and compare the result to confirm.
JonChesterfield 5y ago
It's normally taken as binary + transitive dependencies are bitwise identical on multiple builds. Needs a copy of a deterministic compiler along with your source. Whether the build runs the same on different machines is orthogonal to consistently rebuilding it.
enriquto 5y ago
Reproducibility is certainly achievable, and an important point for some people. Look for example at guix, that bootstraps explicitly with what they call "the maxwell equations of software". Imposing a web-based build system, into the kernel of all places, is a kick to the face to people who care about reproducibility.
- sanderjd 5y ago
  This would definitely be done by "vendor"-ing all the dependency sources into the tree, no? Unless that's not the proposal, which I can't imagine it isn't, then I don't see how "web-based" is relevant.
deleted 5y ago
[deleted]

IshKebab 5y ago

Reproducibility is absolutely achievable. It is difficult with languages that have C system dependencies like C and Rust though. Usually you have to effectively check the compiler and system headers into your repo, which isn't ideal. For something like Go it's trivial though. If you're using pure Go code then reproducible builds are pretty much as simple as "compile using Go 1.xx". I don't understand why you think 3. and 4. are issues. Bit flips are very unlikely at compilation scale, and the hardware you use to compile something shouldn't affect the output. In either case you can just compile it twice and on different hardware and compare the result to confirm.

JonChesterfield 5y ago

It's normally taken as binary + transitive dependencies are bitwise identical on multiple builds. Needs a copy of a deterministic compiler along with your source. Whether the build runs the same on different machines is orthogonal to consistently rebuilding it.

enriquto 5y ago

Reproducibility is certainly achievable, and an important point for some people. Look for example at guix, that bootstraps explicitly with what they call "the maxwell equations of software". Imposing a web-based build system, into the kernel of all places, is a kick to the face to people who care about reproducibility.

sanderjd 5y ago
This would definitely be done by "vendor"-ing all the dependency sources into the tree, no? Unless that's not the proposal, which I can't imagine it isn't, then I don't see how "web-based" is relevant.

deleted 5y ago

[deleted]