Hacker News Reader

Comment by dingdingdang | Hacker News Reader

So happy someone are spending time on this issue, it's like a breath of fresh air and intelligence in the midst of all the usual software (security/privacy/etc. take your pick) mayhem. It's worth reading https://reproducible-builds.org/ for a brief (re-)reminder on why this project is important.

Outtake: "With reproducible builds, multiple parties can redo this process independently and ensure they all get exactly the same result. We can thus gain confidence that a distributed binary code is indeed coming from a given source code."

View on HN

Reproducible builds are extremely useful. There are more benefits. For example, suppose you have a build server compiling software packages. If your builds are not reproducible and you want to debug a core dump, but you have no debug information, you are out of luck (well, you could dive into the assembly code, but it's inconvenient). If you want to keep debug information, you need to store them for every single build (what a waste of storage...) because the binary for each build is different. Not so with reproducible builds, you could simply check out the old version and compile it with debug information!

Most huge Debian packages carry a separate -debug package so you can get the symbols without huge recompilation times + having to set up a buildchain and associated dev libraries of all the packages.

Similarly Gentoo has 'splitdebug': https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backt...

I'm nitpicking here, but the convention is -dbg or (recently) -dbgsym as the suffix for packages in the Debian repositories. The Debain repository containing the debug packages itself itself is suffixed with -debug though, as in "unstable-debug".

If you're interested, the old way was to have an explicit -dbg package which often had to be requested, but now they can mostly autogenerated into -dbgsym packages. These are also uploaded to a separate archive these days too to keep the mirror sizes down.

Well, reproducible builds doesn't necessarily mean that it stays reproducible when you turn on debug info.

If both builds turn on debug info, why wouldn't they still be the reproducible?

Debug information often is choc-full of environment specific goodies that can easily cause builds not to be reproducible.

For example, debug information for several languages I've worked with embed the full path to where the source code file was originally compiled. This can easily vary across two machines in a way that when debug information is turned on, the builds are different, but when turned off they are the same.

While the reproducible builds efforts try to make builds path-independent, at the moment they often settle for reproducibility when built at the same common path. That's still enough that you can reproduce the build yourself.

Does path-independent mean what I think it means? One thing I hate about Linux is having to set prefix at build time. You can't tar up a software and move to your home directory on another machine. That and the lack of compatibility between base libraries/kernels means you can't hope to upgrade chrome for yourself easily like anyone on Windows or Mac can trivially do.

No, in this case it just means binaries won't contain / depend on the path you used to compile it in.

You are correct, but to use a core file with debug info, the binaries don't have to be bit-perfectly identical. All that has to be equal is the offset of each function and statement and that is the case in reproducible builds. Debug info is only "tacked on"; you can strip a binary, generate a core dump and then use the original binary with debug information to debug the core dump.

those kinds of differences are exactly part of what the reproducible builds project has worked on

however debug symbols and "debug mode" are two different things.. at least in debian packages are generally compiled with debug symbols on, then separated into a separate package automatically and stripped into the final package as a separate step.

more here: https://reproducible-builds.org/docs/build-path/

Another wonderful side effect: making it easier to change out other parts of the build infrastructure while being able to verify that you haven't broken anything. e.g. trying out experimental changes to ccache.

Reply on news.ycombinator.com