summaryrefslogtreecommitdiff
path: root/website/posts/reproducible-build-summit.html
blob: f2506b87838fd509f0328a556cd149cd1ef02b54 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
title: Reproducible Build Summit, 2nd Edition
date: 2016-12-16 18:00
author: Ludovic Courtès, John Darrington, Ricardo Wurmus
---
<div> <!-- needed to placate Haunt's 'html-reader' -->
  <p>
    GNU Guix was present this week at
    the <a href="https://reproducible-builds.org/events/berlin2016/">second
    Reproducible Build Summit</a> in Berlin.  Three of us were there.
    We happily joined a dozen of other free software projects, mostly
    distros, to discuss cross-cutting reproducibility issues going from
    outreach to hacking on a specific piece of software.  This attempts
    to summarize important points that were discussed in some of the
    sessions we attended, and how Guix fits into that.
  </p>

  <h4>On reproducibility</h4>
  <p>
    What does it mean for a build process to be <i>reproducible</i>?
    That sounded obvious to many attendants, but experience has shown
    that many outside of the community needed clarifications.  A group
    led by Ed Maste of FreeBSD worked hard to come up with a definition
    that is both concise, accurate, and generic.  Impressive and useful
    work!
  </p>
  <p>
    At the same time, another group worked on the other thankless task
    that consists in
    improving <a href="https://reproducible-builds.org/docs/">the
      reproducible build documentation</a>.  A big thanks to them!
  </p>

  <h4>Testing reproducibility</h4>
  <p>
    For a couple of years, Debian has had
    a <a href="https://tests.reproducible-builds.org/debian/reproducible.html">
    dashboard</a> that shows the progress that has been made.  The
    result is impressive: 92% of its source packages are now bit-for-bit
    reproducible!  During the meeting, Eelco Dolstra reported first
    results for NixOS, obtained thanks to an extension to
    the <a href="https://nixos.org/hydra/">Hydra</a> continuous
    integration tool:
    <a href="http://lists.science.uu.nl/pipermail/nix-dev/2016-December/022329.html">77%
      of the packages</a> are currently reproducible.
  </p>
  <p>
    Our build farm in Guix doesn't yet have the resources to perform
    independent rebuilds of packages.  We plan to use the shared
    resources
    at <a href="https://tests.reproducible-builds.org/">tests.reproducible-builds.org</a>
    to achieve that soon.  Since last year's summit,
    our <a href="https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html">patch
    submission guidelines</a> require submitters to check for
    reproducibility issues using <tt>guix build --rounds=<i>N</i></tt>.
    This has already allowed us to fix lots of reproducibility issues in
    packages.
  </p>

  <h4>User-facing interfaces to reproducible builds</h4>
  <p>
    Reproducible builds should allow users to verify builds, and
    distributors to no longer be single points of failure.  But how
    can we actually <emph>empower</emph> users with reproducible builds?
    Last
    year, <a href="https://www.gnu.org/software/guix/news/reproducible-builds-a-means-to-an-end.html">we
    outlined</a> that reproducible builds are a means to user
    empowerment.  Thus it was great to brainstorm these issues with
    brilliant minds!
  </p>
  <p>
    dkg of Debian and ACLU led a couple of sessions on this topic.
    Tools
    like <a href="https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-challenge.html"><tt>guix
    challenge</tt></a> are one way to help users check whether their
    binaries are trustworthy, provided independent package builds are
    available.  Some suggested that this could be used as an input for a
    more general kind of “system health” monitoring tool.
  </p>
  <p>
    A large part of the discussion then focused on <emph>policies</emph>
    that users could select.  For example, assuming several independent
    organizations provide binaries for a given distro, users could
    disallow installation of binaries for which providers disagree on
    the output.  Worded like this, the policy could easily lead to
    denial of service should one of the providers be unavailable.  A
    refinement of this policy is to install only packages for
    which <i>k</i> out of <i>n</i> known builders “agree” on what
    the package contents are.
  </p>
  <p>
    Guix currently allows users to specify multiple binary providers
    through
    the <a href="https://www.gnu.org/software/guix/manual/html_node/Substitutes.html"><tt>--substitute-urls</tt></a> option.
    We hope we can extend it to support this “<i>k</i> out of <i>n</i>”
    policy by the next Reproducible Build Summit!
  </p>

  <h4>Bootstrapping</h4>
  <p>
    The Summit focuses on reproducible <emph>builds</emph>, but
    unfortunately, there are more and more situations where software is
    not built from source.  In most cases, this is due
    to <emph>bootstrapping issues</emph>: a compiler is written in the
    language it compiles, and thus distributors have no choice but to
    start from an opaque pre-built binary provided by upstream.  The
    problem also comes up
    when <a href="https://www.gnu.org/software/guix/manual/html_node/Bootstrapping.html">building
    a complete system “from nothing”</a>.  This situation prevents users
    from knowing what code they’re running, and it makes them vulnerable
    to <a href="https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html"><i>trusting
    trust</i> attacks</a>.
  </p>
  <p>
    In Guix, the debate came up every time we added one of these
    self-hosted compilers—Rust, OCaml, GHC, etc.  This is not a
    comfortable situation.  We led sessions on this topic with two
    goals: to try and make a specific package “bootstrappable”, and to
    raise awareness and come up with guidelines for compiler and tool
    writers.  Together with other hackers, we drafted a manifesto that
    we hope to publish soon.  Stay tuned!
  </p>

  <h4>Hacks!</h4>
  <p>
    During the hacking sessions, while Ricardo was busy working on the
    bootstrapping manifesto, John together with Pierre Pronchery of NetBSD
    tackled <a href="https://savannah.gnu.org/bugs/?49654">gettext reproducibility issues</a>, and
    Ludovic picked up the work of others on fixing
    a <a href="https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20272">longstanding
    reproducibility issue in Guile</a>, the Scheme implementation used
    by Guix—“the shoemaker’s child always goes barefoot”, they say.
  </p>

  <h4>Thanks!</h4>
  <p>
    We would like to thank the sponsors who helped make the Reproducible
    Build Summit possible: Debian, Google, Linux Foundation, and Open
    Tech Fund.  Special thanks to Beatrice and Gunner of Aspiration and
    to Holger of Debian for the perfect organization, and for the
    productive and friendly atmosphere they created!
  </p>

  <h4>About GNU Guix</h4>
  <p>
    <a href="https://www.gnu.org/software/guix">GNU Guix</a> is a
    transactional package manager for the GNU system.  The Guix System
    Distribution or GuixSD is an advanced distribution of the GNU system
    that relies on GNU Guix
    and <a href="https://www.gnu.org/distros/free-system-distribution-guidelines.html">respects
      the user's freedom</a>.<br /></p><p>In addition to standard package
    management features, Guix supports transactional upgrades and
    roll-backs, unprivileged package management, per-user profiles, and
    garbage collection.  Guix uses low-level mechanisms from the Nix
    package manager, except that packages are defined as
    native <a href="https://www.gnu.org/software/guile">Guile</a> modules,
    using extensions to the <a href="http://schemers.org">Scheme</a>
    language.  GuixSD offers a declarative approach to operating system
    configuration management, and is highly customizable and
    hackable.<br />
  </p>
  <p>
    GuixSD can be used on an i686 or x86_64 machine.  It is also possible
    to use Guix on top of an already installed GNU/Linux system, including
    on mips64el and armv7.
  </p>
</div>