Fedora 41 Approved To Make Package Builds More Reproducible

[phoronix]

Phoronix: Fedora 41 Approved To Make Package Builds More Reproducible

In addition to approving -O3 optimized Python builds, the Fedora Engineering and Steering Committee (FESC)) this week unanimously approved a Fedora 41 change proposal for making RPM package builds more reproducible...

https://www.phoronix.com/news/Fedora-41-More-Reproducible

[uid313]

Canonical needs to look into this too for Ubuntu!

[rene]

pretty cool. Only 20 years after T2/Linux https://t2sde.org ;-)

[Jumbotron]

Canonical needs to look into this too for Ubuntu!

Amen and amen. Let it be so.

[mSparks]

does anyone know how builds became non deterministic in the first place? How was this ever a thing?

[luno]

does compiler optimisations like LTO/BOLT are compatible with this (i have read somewhere it is possible), In NixOS they disable many compiler optimisation due to Reproduciblity

[Jaxad0127]

does anyone know how builds became non deterministic in the first place? How was this ever a thing?

A lot of it is metadata. Time stamps, local paths, etc. The goal of reproducible builds is for independent parties to be able to create identical binaries, so embedded metadata needs cleaning.

[mSparks]

A lot of it is metadata. Time stamps, local paths, etc. The goal of reproducible builds is for independent parties to be able to create identical binaries, so embedded metadata needs cleaning.

surely verifying binaries can just ignore the metadata?, this seems like something far more insidious.

also, metadata is still deterministic, non deterministic implies the binaries change randomly even when metadata is otherwise identical.

[ssokolow]

surely verifying binaries can just ignore the metadata?, this seems like something far more insidious.

also, metadata is still deterministic, non deterministic implies the binaries change randomly even when metadata is otherwise identical.

You're assuming it's ELF metadata, rather than things like timestamps baked into the object code via things like preprocessor defines. (eg. some applications put their build timestamps in their --version output)

As for deterministic vs. non-deterministic, their definition of non-determinism is broader, also covering information leaking in through side-channels not covered by their build plans, such as calls to strftime to generate those --version strings which back onto calls like localtime during the build process.

[mSparks]

their definition of non-determinism is broader

OK.
So are builds creating randomly different binaries or not?