Fedora Targets 99% Package Reproducibility by October (lwn.net) 21
Fedora has proposed a major change for its upcoming version 43 release that aims to achieve 99% package reproducibility, addressing growing concerns about supply-chain security. According to the change proposal announced March 31, Fedora has already reached 90% reproducibility through infrastructure changes including "clamping" file modification times and implementing a Rust-based "add-determinism" tool that standardizes metadata. The remaining 10% will require individual package maintainer involvement, treating reproducibility failures as bugs.
The effort will use a public instance of rebuilderd to independently verify that binary packages can be reproduced from source code. Unlike Debian's bit-by-bit reproducibility definition, Fedora allows differences in package signatures and some metadata while requiring identical payloads. The initiative follows similar efforts by Debian and openSUSE, and comes amid heightened focus on supply-chain security after the recent XZ backdoor incident.
The effort will use a public instance of rebuilderd to independently verify that binary packages can be reproduced from source code. Unlike Debian's bit-by-bit reproducibility definition, Fedora allows differences in package signatures and some metadata while requiring identical payloads. The initiative follows similar efforts by Debian and openSUSE, and comes amid heightened focus on supply-chain security after the recent XZ backdoor incident.
Hah, about time... (Score:2)
I would guess that a majority of competing Linux distributions were launched in the past 30 years from Redhat's complete lack of giving a shit about how, when, with what, and on what actual system their packages were made.
Re:Hah, about time... (Score:4, Interesting)
But Arch is probably superior to Fedora in literally every technical way. Much better architects and engineers.
Re: (Score:2)
I don't get this part (Score:5, Interesting)
I don't see how this would have done anything to prevent the "XZ backdoor incident", since that code was inserted by a trusted maintainer.
Re: (Score:2)
It's about getting the last 10% of the "trusted maintainers" inline.
Re: (Score:3)
I don't see how this would have done anything to prevent the "XZ backdoor incident", since that code was inserted by a trusted maintainer.
What the XZ incident did was raise the awareness level of supply chain attacks (the vulnerability was always acknowledged; that the XZ maintainer almost succeeded increased the concerns). Reproducible builds are just one part of the process to raise the bar.
Re: (Score:2)
A reproducible build means you can take the source code of a release, build it and package it, then take it again some other time, build it, and end up with every file being exactly the same.
Things that can mess with such a thing include embedded timestamps in code, bundling files in archives (many archive formats preserve date and time), and other such things that can change from build to build.
Some things cannot be made reproducible - encrypted objects, for example, often contain a nonce or other random e
Re: (Score:3)
Reproducible means you can verify what the maintainer did.
For XZ, there was a tar for download that didn't match the contents of the git. As there were no reproducible instructions how to build the tar from git (it involved generating random looking test data) one would not have the chance to verify if someone injected data from outside the repository.
If they had a reproducible build script, you could build the release yourself and compare against the official version. If there is a mismatch, someone (possi
Re: (Score:2)
Trust but verify.
Re: I don't get this part (Score:2)
+9000
There are many ways to compromise.
Re: (Score:2)
It isn't, it's about doing something geeky that lets you say you've done something about something.
And you're correct, it does nothing to deal with backdoors since all you're guaranteeing is reproducibility of the backdoor. In fact it's hard to identify what useful purpose it serves beyond the one mentioned above. Arguably it's actually a net loss for security since an guaranteed-identical memory layout each time makes it much easier to craft ROP exploits and similar.
Re: (Score:2)
Does this really prevent ASLR? I was under the impression that happened at runtime, while this is about getting the same binary out of the compilation process.
Feeling better about switch to Debian ... (Score:1)
Re: (Score:2)
Why exactly? Debian is going through this exact same issue as we speak.
Re: (Score:2)
This seems like a scenario where we all win.
Red Hat does their twiddling for RPM but in turn upstreams anything helpful to the source project, allowing rival package formats such as Arch, deb, pkgsrc etc to adopt reproducible builds too.
Re: (Score:1)
Why exactly? Debian is going through this exact same issue as we speak.
It seems like Debian is doing a more thorough job from what was written.
Re: (Score:3)
Why exactly? Debian is going through this exact same issue as we speak.
It seems like Debian is doing a more thorough job from what was written.
Debian has to do things differently because, unlike Fedora, Debian allowed (under some circumstances) packagers to upload resulting files directly to the repos, and apt uses detached (rather than embedded, as in rpm) signatures. Fedora requires all packages to build from source in their dist-git on their build infrastructure. The goals are the same (reproducability), but the implementations and schedules are different because they have different things to address in their procedures and infrastructure. A
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Have you met many Debian users? They all seem to be the old guy in the rubber mask Scooby and gang unmasks at the end of the episode.
Re: (Score:2)
Can identify. :)
I'm grateful for Mr Shuttleworth for mailing me those Warty Warthog CDs all those decades ago when I was still on dialup. But Ubuntu added various enhancements that, well, had me trying upstream and Debian works well enough without too much drama.