4 ms·
> Reproducible builds are useful for purposes other than security, though. I've been using an off-the-wall build system called Tup [0], which is designed to su
by gavinpc 11y ago
> Reproducible builds are useful for purposes other than security, though.
I've been using an off-the-wall build system called Tup [0], which is designed to support optimally fast incremental builds (i.e. build times that don't scale with the codebase), and it calls for some of the same constraints, chiefly, a strictly deterministic build (no timestamps, control access to environment variables and all file IO). It even deletes generated files when they leave the graph for any reason (being philosophically opposed to a "clean" target). It's an opinionated tool, but it does deliver on its promise.
The author also maintains (or at least used to maintain) a Linux repo/distro that is somewhat in the spirit of the OP, at least to the extent that git implements a kind of blockchain.[1]
So yeah, there's considerable overlap between this and properties that I'd think everyone would want. The cost is a change in some habits.
[0] http://gittup.org/tup/ http://gittup.org/tup/
https://github.com/gittup/tup/ https://github.com/gittup/tup/
[1] http://gittup.org/gittup/ http://gittup.org/gittup/
- josteink 11y ago> a strictly deterministic build (no timestamps In some environments, you really need a timestamp, otherwise your code will be treated as untrusted/unsigned by the OS after the signing certificate expires. This for instance applies to X509-signed code and EXE-files on Windows. Does this mean that if you want reproducable builds, you have to use a signing-certificate valid looong into the future? Are there any other ways? Are there any downsides? Anyone have opinions or experience here?
- throwaway7767 11y agoI'm not familiar with how code signing for PE executables is performed, but I imagine it's done as a seperate step after compilation? If so, what matters is that the binary pre-signing is reproducible. Ideally we should be able to remove the signature for the binary, build our own, and get a bit-identical binary.
- geofft 11y agoYeah, it's done as a separate step, and I believe it's an independent section of the file (such that you can add and remove it at will). If you recompile a bit-identical unsigned binary, you should be able to take the previous signature (including third-party timestamp!) and snap it onto that binary. You just have to treat that signature itself as data. I believe this is actually roughly the approach Debian wants to take with Secure Boot: build the loader (which is a PE binary), sign it on a secure machine, then drop the signature into the Debian source package and rebuild it. That way anyone can grab the Debian source package and `dpkg-buildpackage` it and get a validly signed bootloader, provided they haven't changed the sources and they're using the same toolchain.
- voltagex_ 11y agoWow, I didn't even think of this usecase before seeing it mentioned here. I hope they make some kind of reproducible-pbuilder which pulls the right version of the toolchains - pbulder/sbuild/cowbuild can be really difficult to set up.