openSUSE Factory Achieves Bit-By-Bit Reproducible Builds

[Setif]

wait, what- won't the same source code compiled with the same dependencies provide the same binary?

Not always, some code contains reference to time, os ...

[aerospace]

From a security standpoint, that now makes them my number one Linux distro to use when security is of the utmost importance.

Very nice job, YES, but I wouldn't rush too much with claims, as reproducibility is just one of the many, many aspects that contribute to security..

[keit99]

wait, what- won't the same source code compiled with the same dependencies provide the same binary?

anyway, opensuse is heavily underrated distribution

Interestingly, no they won't build systems may take things into the count like times, dates, and other metadata, that aren't fixed resulting in a different binary, that is functionally the same, but not a bit by bit recreation when built from source on a different machine

EDIT: just saw someone already mentioned that

Distributions that are (mostly) reproducible are Arch linux and debian (>90% on x86_64)

[DumbFsck]

Really a great achievement.

Honestly Factory, OBS and OpenQA are so underrated it saddens me.

[kuuchan]

Another distribution that has been doing a lot of work on the related topics of full-source bootstrapping and build reproducibility for quite a few years now is Guix. When I last looked at the numbers, I believe the figures were above 90% for x86_64; however it has been more than a year since I last checked and https://data.guix.gnu.org/repository...eproducibility isn't currently accessible.

A couple of good sources of information on build reproducibility are https://reproducible-builds.org/ and, for a more detailed view of issues that can arise and work that is being done, the Guix blog at https://guix.gnu.org/en/blog/ (in particular https://guix.gnu.org/en/blog/tags/reproducibility/ which looks to include a small number of posts with more general information, and https://guix.gnu.org/en/blog/tags/reproducible-builds/ which includes more Guix-specific posts such as specific milestones, etc).

[pong]

What're some good ways to verify the installed files on the file system match the ones that the distribution's package system installed as parts of packages?
i.e. look for whether the system files and such correspond to ones in officially installed & signed packages or are different since installation?

Obviously one can hash the present files after and maybe also before / otherwise every package installation / update and see what changed but since the
repo packages themselves are signed and I suppose may have manifests available with the content hashes I wonder if there's an easy way to compose / keep / check against the upstream package hash lists which may be downloaded / cached during a package installation anyway.

[bmwiedemann]

Besides openSUSE, Debian and Archlinux also spend significant effort on reproducible builds.
So far Fedora only tries for semi-reproducible - ignoring several metadata bits in a custom compare tool. We also did that for practical reasons with our build-compare tool. However, there is always the danger that such a tool misses out on significant changes.

For openSUSE rpm verification, I now use rpm --delsign to drop the embedded signature and get over 13300 bit-identical packages from rebuilds.

Since Tumbleweed is rolling, I also keep an index of old binaries in IPFS at http://opensuse.zq1.de/ and use the _buildenv files (available via OBS API) to locate the right versions.

@pong: you can use rpm -qaV and ignore files tagged as config (c) or ghost (g).

[bmwiedemann]

wait, what- won't the same source code compiled with the same dependencies provide the same binary?

right. I collected 10 reasons for non-determistic build results in https://github.com/bmwiedemann/theun...uciblepackage/ and https://reproducible-builds.org/docs/commandments/

[chocolate]

Depends on the definition: https://linderud.dev/blog/nixos-is-not-reproducible/

Incoherent, ill-written ramblings and pseudo erudite regurgitation.

[spicfoo]

It can also, also be argued that RHEL will fucking hate this. Reproducible builds turned into distributions is basically what Rocky, Alma, etc are.

You are conflating ABI compatibility with reproducible builds. They are not the same thing. Nobody using clones care about the latter. Some of the clone users care about the former. Phoronix already covered the news that Red Hat developers are actively working on the same thing. It wouldn't make sense for them to allot resources to something they hate.