19/05/2024 18:36, Luca Boccassi: > On Sun, 19 May 2024 at 15:01, Thomas Monjalon <tho...@monjalon.net> wrote: > > 17/05/2024 13:29, Luca Boccassi: > > > On Mon, 27 Nov 2023 at 17:04, Bruce Richardson > > > <bruce.richard...@intel.com> wrote: > > > > > > > > On Mon, Nov 27, 2023 at 05:45:52PM +0100, Thomas Monjalon wrote: > > > > > I would prefer adding an option for reproducible build > > > > > (which is not a common requirement). > > > > > > > > > Taking a slightly different tack, is it possible to sort the > > > > searchindex.js > > > > file post-build, so that even reproducible builds get the benefits of > > > > parallelism? > > > > > > Given the recent attacks with malicious sources being injected in open > > > source projects, reproducible builds are more important than ever and > > > should just be the default. > > > > Yes it should be the default when packaging. > > Why should it be the default for normal builds? > > Build reproducibility is everyone's responsibility, not just Linux > distributions. There should be no difference between a "normal build" > and a "packaging build". As far as I know, it is still fully supported > for DPDK consumers to take the git repository, build it and ship it > themselves - those cases also need their builds to be reproducible.
Sorry I really don't understand this point. The goal of a reproducible build is to maintain a stable hash, right? This hash needs to be stable only when it is published, isn't it? So isn't it enough to give a build option for having a reproducible build? > Nowadays reproducibility is no longer a "nice-to-have", it's table > stakes, as especially after the cybersecurity executive order of the > US govt from some time ago, procurement rules are getting stricter. > See the "Reproducible Builds" paragraph under the "2.4 Harden the > Build Environment" section in this CISA document on supply chain > security recommendations: > > https://www.cisa.gov/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF
