On Thu, 7 Mar 2024 at 18:38, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote:
On Thu, Mar 07, 2024 at 10:01:08PM +0000, Richard W.M. Jones wrote:
> On Thu, Mar 07, 2024 at 12:39:37PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
Nevertheless, for me, reproducibility is interesting because it aids
debugability, and "threats" are not an immediate concern. Essentially, when the
builds are stable, any unexpected change in the build outputs is much easier to
diagnose. We have already found and submitted a bunch of obvious fixes that
would not have been found otherwise. Also, when builds are stable, when working
on the tools, it is easy to do a rebuild with the patched tools and observe the
diff. If the build is "unstable", i.e. there are various other unrelated
changes, interesting differences often drown in noise.
Now this is the part which is the real important part which gets overlooked a lot.
As much as some people somehow make it out that reproducibility will make things secure.. it will only do so against a threat which isn't as existent as people injecting bad source code. [Supply chain attacks are already just including bad source code which will build reproducible but still be bad. It is much cheaper to make mostly useful but compromised code into pypi, cpan, some cargo place etc and getting other people to need to include it in a distro or just straight to a developer than it is to break into Fedora/Debian/etc and compromise a gcc ]
The real fix is in Quality and catching things which silently make builds bad. A CPU problem, a memory problem, a builder kernel issue, etc are bigger problems and more likely to cause hard to fix bugs because they aren't bugs in the code. Of course this means that builds need to be built twice inside a build system to make sure that both builds match.. otherwise you can end up where someone rebuilding starts reporting problems with our build system but its because they used overclocked ram or cpu :)
E.g. today I ended up creating a pull request for intltool package [1],
backporting a patch to fix a race in cache creation which was corrupting
translations in files. The patch is from 2015, but seemingly nobody noticed the
issue in Fedora so far.
More examples are [2,3], one of the many examples of noarch packages using
arch-dependent macros, e.g. %_libdir, leading to packages that are "noarch",
but actually depend on the build architecture, and misbehave when installed
on a system with a different architecture than the build machine.
[1] https://src.fedoraproject.org/rpms/intltool/pull-request/2
[2] https://src.fedoraproject.org/rpms/xbyak/pull-request/5
[3] https://src.fedoraproject.org/rpms/python-virt-firmware/pull-request/3
Zbyszek
--
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
