On Thu, 7 Mar 2024 at 18:38, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
