On Fri, 31 Mar 2017 07:52:23 -0400, Nicolás A. Ortega wrote: > > - Reproducible builds > > > > Last year at LibrePlanet I attended h01ger's talk on reproducible > > builds. I went in with the attitude that reproducible builds were > > nice, but that Parabola would never have them. But I came out > > thinking "Parabola will be reproducible by next LibrePlanet." That > > didn't happen, because I'm a lazy fuck. > > > > This involves doing a better job of tracking exactly what source > > went in to a package. I have the necessary changes to libretools > > already planned. > > > > As far as enforcing reproducible builds (which would be the *very* > > last step), I was thinking that it should require the package to be > > built 3 different times: 2 by build servers, and once by a human. > > > > This also means we need to redo db-cleanup to not prune packages > > mentioned in any current package's `.BUILDINFO`. > > I have heard a lot about reproducible builds as of lately, however I > fail to see how effective it would actually be against the issue they > are trying to solve, especially considering the extremely low risk of > the issue existing to begin with. There is a blog post that I believe > does a good job at summarizing the issue[0] (if you can get passed all > of the smart-ass remarks). > > [0] > https://www.tedunangst.com/flak/post/reproducible-builds-are-a-waste-of-time
You are talking about verifiable builds. Reproducible builds (R-B) are a prominant strategy for implementing verifiable builds, and verifiable builds are certainly a large part of the push for R-B. To borrow from from the post you linked: | Of course, there are uses for reproducible builds besides shutting | down the CIA. When migrating from an old build server to a new one, | it definitely helps to know that the same product is being | built. Builds that can’t be reproduced are more likely to | accidentally incorporate hidden dependencies. A reproducible build | is, by necessity, a deterministic build. Having struggled with | “random” build failures at various times, I’m all in favor of more | deterministic builds. THOSE REASONS. To borrow some more reasons that I find compelling from the Debian wiki page that Ted linked <https://wiki.debian.org/ReproducibleBuilds/About>: | - Be able to generate debug symbols for packages which do not have a | “debug package”. Oh my God, yes please. | - Ensure packages can be built from source. We've had cases where a nescessary file accidentally gets ommitted from abslibre.git. | - Packages with build profiles must offer the exact same | functionality for all profiles. Reproducible builds could be use | to verify that it is the case. To translate into pacman terms: verify that innocent changes to BUILDENV (ccache, distcc, et c.) actually are innocent. | - Validate cross-builds against native builds. > My own criticism of it is that it creates the ironically named "chicken > or the egg" paradox[1]. This problem is called the "trusting trust" problem (named by Ken Thompson). R-B don't try to address trusting trust. That isn't a problem that is even purported to be solved by R-B. However, trusting trust *was* solved in 2005 by David Wheeler with a solution called "Diverse Double-Compilation" (DDC). R-B are a prerequisite for DDC. -- Happy hacking, ~ Luke Shumaker _______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
