Adding package information to ELF objects

Posted Nov 3, 2021 5:00 UTC (Wed) by pabs (subscriber, #43278)
Parent article: Adding package information to ELF objects

This is going to eliminate build reproducibility when using different versions of build dependencies, which normally happens when those dependencies.

The main thing I've learned from the reproducible builds project is that data about a build should not be stored in the build products for that build, but in the metadata about that build. For eg you shouldn't put the build log in a .rpm but in a .log file beside that RPM, and you shouldn't record the build dependency versions used to build an RPM in the RPM, but in a buildinfo file next to the RPM.

Adding package information to ELF objects

Posted Nov 3, 2021 5:03 UTC (Wed) by pabs (subscriber, #43278) [Link]

... when those dependencies changed only in minor ways.

Adding package information to ELF objects

Posted Nov 3, 2021 5:14 UTC (Wed) by jhoblitt (subscriber, #77733) [Link]

At least the examples in the wiki should be stable between rebuilds of the same srpm. Nothing as bad as a timestamp or digest.

Adding package information to ELF objects

Posted Nov 3, 2021 7:43 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

IMHO, if any of the code is actually different (results in a different sequence of instructions executing at runtime), then it's a new build and should not be easily confused with an old build. But then at Google we statically link everything, so maybe this is different for people living in the dynamic universe.

Adding package information to ELF objects

Posted Nov 3, 2021 11:46 UTC (Wed) by bluca (subscriber, #118303) [Link]

It's the same, and the reproducible builds specification does explicitly mention the build env:

> When is a build reproducible?
> A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.

> Relevant attributes of the build environment would usually include dependencies and their versions, build configuration flags and environment variables as far as they are used by the build system (eg. the locale).

https://reproducible-builds.org/docs/definition/

If the build environment changes, it is not expected to be able to create the same binary, and that's why it's all recorded in the buildinfo, to be able to reproduce it.

Adding package information to ELF objects

Posted Nov 3, 2021 10:41 UTC (Wed) by bluca (subscriber, #118303) [Link]

Why would it? If the same source package is used, and source metadata are added, then it's going to be the same. Metadata from dependencies is not encoded in a binary, each elf carries its own info. And it's logical: a library might get updated, so it's metadata might change at runtime, so it wouldn't make sense to record it.

But even if it did, changing the build toolchain will result in changes in the binary, and that's ok, the installed environment is recorded in the buildinfo for that reason. Reproducible builds are not about minimizing changes in arbitrary ways, they are about being able, given the same input (sources plus toolchain/dependencies), to get the same output. Build deps, compiler, etc are very much part of the input.