|author||intrigeri <firstname.lastname@example.org>||2017-02-07 01:46:02 +0000|
|committer||intrigeri <email@example.com>||2017-02-07 01:46:02 +0000|
Merge remote-tracking branch 'origin/devel' into feature/tor-nightly-master
Diffstat (limited to 'wiki/src/blueprint/reproducible_builds.mdwn')
1 files changed, 93 insertions, 0 deletions
diff --git a/wiki/src/blueprint/reproducible_builds.mdwn b/wiki/src/blueprint/reproducible_builds.mdwn
index dcab246..3723a38 100644
@@ -2,6 +2,8 @@ This is about [[!tails_ticket 5630]].
# Why we want reproducible builds
## List of reasons why
@@ -501,3 +503,94 @@ It also raises technical questions:
- ask Chris Lamb <firstname.lastname@example.org> (keywords: libisofs,
- [[!debbug 831379]] / [[!debbug 832689]]
+See [[our November report|news/report_2016_11]].
+# Future work
+## Make it easy to recreate a given build environment
+It would be great if one didn't have to trust a given Vagrant basebox
+we published, and could instead build their own. Their resulting basebox
+doesn't have to be identical to ours, but it must be similar enough to
+produce ISO images that are identical to ours.
+## Integrate custom Debian package builds in the automated ISO builds
+In our first iteration of reproducible ISO builds, we treat the
+content of the Debian package repositories used during the build
+process as trusted input. These repositories are of two kinds:
+ * snapshots of the Debian archive, hosted on our own infrastructure,
+ and signed server-side by our own key; Tails system administrators have the
+ power to modify the content of these snapshots; an attacker who
+ takes control of the relevant server can do the same; this will be
+ improved later, and is outside of the scope of the work described
+ in this section;
+ * our [[custom APT repository|contribute/APT_repository/custom]],
+ that stores our custom Debian packages; in addition to the people
+ listed above (system administrators, successful attackers), Tails
+ developers with commit rights can modify the content of this
+ repository. The current standard process is that a developer builds
+ a package locally, and uploads it to our custom APT repository.
+ This entails a number of problems that we are going to discuss now.
+Here are some problems that come with our current handling of custom
+ * Each developer needs to set up and maintain a local build
+ environment for Debian packages. Such error-prone busywork is
+ best avoided.
+ * Our custom Debian packages may not build reproducibly across
+ different developers' systems. So, one can't reproduce the build of
+ a given ISO unless they use the exact packages that were uploaded
+ to our custom APT repository. This brings the same
+ [[set of problems|reproducible_builds#why]] that lead us to make
+ our ISO image build reproducibly. For example, the state of our Git
+ tree does not fully define what an ISO built from it will be, which
+ makes reviewing and auditing harder than it should be.
+ * Preparing a Tails release requires to build and upload a few
+ packages by hand. This work is tedious and error-prone, and
+ increases our time to mitigation for security issues.
+ * Preparing a Tails release requires special credentials on our
+ infrastructure, while we are moving towards Git access
+ being enough.
+The way we have chosen to address these problems in the future is to
+have our custom Debian packages built automatically, in a reproducible
+manner, as part of building a Tails ISO image.
+There are a number of open questions:
+ * Is it better to apply this build process change to _all_ ISO
+ builds, or only to selected ones, e.g. actual releases?
+ * Shall the Debian packages built as part of the ISO build be
+ uploaded, stored and published somewhere? Or should they be
+ considered as intermediate results we can just throw away after
+ installing them?
+ * If we upload these packages, how will they be verified by future
+ builds using them?
+ * How exactly shall these custom Debian packages be built? Can we do
+ this inside the Vagrant build virtual machine?
+ * What kind of quality assurance process will the built packages go
+ through? Should it be done as part of the ISO build process, or
+ instead on our continuous integration platform where the packages
+ could be re-built (or uploaded) and checked?
+Part of this project will therefore be to research and discuss these
+topics with the affected parties, and come up with user stories and
+with a fitting design.