[Dev] Goals/direction for the coming year
lukeshu at lukeshu.com
Fri Mar 31 18:49:48 GMT 2017
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 (if you can get passed all
> of the smart-ass remarks).
>  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.
To borrow some more reasons that I find compelling from the Debian
wiki page that Ted linked
| - 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
| - 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.
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.
~ Luke Shumaker
More information about the Dev