[Dev] Goals/direction for the coming year

[Luke Shumaker]

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