The supply chain attacks you have to most worry about are not someone breaking into Fedora build machines.

It's the attacks on the upstream packages themselves.

Reproducible builds would absolutely not catch a situation like the XZ package being compromised a year ago, due to the project merging a contribution from a malicious actor.

A downstream package system or OS distro will just take that malicious update and spin it into a beautifully reproducing build.

Don't let the perfect be the enemy of the good; this doesn't prevent upstream problems but it removes one place for compromises to happen.

I'm not saying don't have reproducible builds; it's just that this is an unimportant justification for them, almost unnecessary.

Reproducible builds are such an overhelmingly good and obvious thing, that build farm security is just a footnote.

Your mere footnote is my soft, soft underbelly.

Any hardening is still hardening.

Reproducible builds COULD fix the xz issues. The current level would not, but github could do things to make creating the downloadable packages scrip table and thus reproducible. Fedora could checkout the git hash instead of downloading the provided tarball and again get reproducible builds that bypass this.

The above are things worth looking at doing.

However I'm not sure what you can code that tries to obscure the issues while looking good.

And anything designed to catch upstream problems like the XZ compromise will not detect a compromise in the Fedora package build environment. Kinda need both.

When builds are reproducible, one thing a distro can do is have multiple build farms with completely different operators, so there's no shared access and no shared secrets. Then the results of builds of each package on each farm can be compared, and if they differ, you can suspect tampering.

So it could help you detect tampering earlier, and maybe even prevent it from propagating depending on what else is done.

Bingo.