[Reproducible-commits] [reproducible-website] 43/55: Add agenda, minutes and links for the Athens meeting
Chris Lamb
chris at chris-lamb.co.uk
Tue Aug 23 13:39:54 UTC 2016
This is an automated email from the git hooks/post-receive script.
lamby pushed a commit to branch master
in repository reproducible-website.
commit e9bd327d72e242dcc03ed32fc27a34b2e851ffdb
Author: Jérémy Bobbio <lunar at debian.org>
Date: Thu Jan 7 15:44:53 2016 +0100
Add agenda, minutes and links for the Athens meeting
Thanks to every notetakers and reviewers.
---
_events/athens2015.html | 23 ++-
_events/athens2015/advocacy_next_steps.md | 55 ++++++
_events/athens2015/agenda.md | 149 ++++++++++++++++
_events/athens2015/benefits.md | 43 +++++
_events/athens2015/bootstrapping.md | 70 ++++++++
_events/athens2015/buildinfo_content.md | 76 ++++++++
_events/athens2015/communicating_with_users.md | 70 ++++++++
_events/athens2015/controlled-build-environment.md | 92 ++++++++++
_events/athens2015/debian_buildinfo_review.md | 51 ++++++
_events/athens2015/diffoscope_wishlist.md | 23 +++
_events/athens2015/fundraising.md | 36 ++++
_events/athens2015/ghc.md | 44 +++++
_events/athens2015/improving_docs.md | 46 +++++
_events/athens2015/issue_database.md | 70 ++++++++
_events/athens2015/next_event.md | 39 +++++
_events/athens2015/post-event_collaboration.md | 49 ++++++
_events/athens2015/reprotest.md | 158 +++++++++++++++++
_events/athens2015/signed_software.md | 79 +++++++++
_events/athens2015/system_images.md | 26 +++
_events/athens2015/unsolved_problems.md | 28 +++
_events/athens2015/use_cases.md | 39 +++++
_events/athens2015/where_from_here.md | 191 +++++++++++++++++++++
22 files changed, 1452 insertions(+), 5 deletions(-)
diff --git a/_events/athens2015.html b/_events/athens2015.html
index 325958e..b51dc39 100644
--- a/_events/athens2015.html
+++ b/_events/athens2015.html
@@ -35,6 +35,24 @@ event_summary: A three days workshop with invited participants from more than 15
</div>
<div class="row">
<div class="four columns title">
+ <h2>Reports</h2>
+ </div>
+ <div class="eight columns text">
+ <ul>
+ <li><a href="{{ "/events/athens2015/agenda/" | prepend: site.baseurl }}">Agenda and minutes</a></li>
+ <li><a href="https://www.joachim-breitner.de/blog/688-Reproducible_Builds_World_Summit">Joachim Breitner, Debian</a></li>
+ <li><a href="https://blog.torproject.org/blog/tor-reproducible-builds-workshop-athens-2015">Georg Koppen, Tor Project</a></li>
+ <li><a href="https://guardianproject.info/2015/12/09/first-reproducible-builds-summit/">Hans-Christoph Steiner, The Guardian Project</a></li>
+ <li><a href="https://lists.macosforge.org/pipermail/macports-dev/2015-December/032016.html">Clemens Lang, MacPorts</a></li>
+ <li><a href="https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/message/DECB4Z2ZSLHPX4W3QPDEPHGWF6PJEII3/">Dhiru Kholia, Fedora</a></li>
+ <li><a href="https://lists.gnu.org/archive/html/gnu-system-discuss/2015-12/msg00000.html">Ludovic Courtès, GNU</a></li>
+ <li><a href="https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00107.html">Ludovic Courtès, Guix</a></li>
+ <li><a href="https://blog.netbsd.org/tnf/entry/reproducible_builds_conference_in_athens">Thomas Klausner, NetBSD</a></li>
+ </ul>
+ </div>
+</div>
+<div class="row">
+ <div class="four columns title">
<h2>Participants</h2>
</div>
<div class="eight columns text">
@@ -43,11 +61,6 @@ event_summary: A three days workshop with invited participants from more than 15
F-Droid, Fedora, FreeBSD, Google, Guardian Project, Guix, Homebrew,
MacPorts, NetBSD, NixOS, OpenWrt, Qubes, Tor.
</p>
- <p>
- <strong>Sorry, but we are full.</strong> Although if you are in the
- area, you can always contact us as we will likely have some gatherings
- outside the meeting.
- </p>
</div>
</div>
<div class="row">
diff --git a/_events/athens2015/advocacy_next_steps.md b/_events/athens2015/advocacy_next_steps.md
new file mode 100644
index 0000000..24e6d7d
--- /dev/null
+++ b/_events/athens2015/advocacy_next_steps.md
@@ -0,0 +1,55 @@
+---
+layout: event_detail
+title: Advocacy: next steps
+event: athens2015
+order: 140
+permalink: /events/athens2015/advocacy-next-steps/
+---
+
+*50-minute session on day 3*
+
+Brainstorm how and where to distribute the idea of reproducible builds.
+
+## Events
+
+ - [FOSDEM’16](https://fosdem.org/2016/schedule/event/reproducible_ecosystem/), January 30-31st 2016
+ - [FLOCK](http://www.flocktofedora.org/), date and location for 2016 unknown
+ - Organise a Google Tech Talk
+
+## Applications to reach
+
+ - Firefox
+ - LibreOffice
+
+## Test systems
+
+ - Have something like rules for Travis so people can put a badge for their project.
+ - Also document recipes for Jenkins.
+
+## People/projects
+
+ - GNU
+ - openSUSE
+ - RedHat
+ - Docker
+ - Universities and CS teachers
+ - Business word (create selling points for companies)
+
+## Misc. things to do
+
+ - Create an icon or badge for projects
+ - Spread *howto*s to developers
+ - Send out press releases
+ - Get into the news
+
+## People who can help
+
+ - Nathan Willes from Linux Weekly News
+ - Richard Stallman
+ - Ben Laurie
+
+## News site to reach
+
+ - LWN
+ - Hackernews
+ - Der Spiegel
diff --git a/_events/athens2015/agenda.md b/_events/athens2015/agenda.md
new file mode 100644
index 0000000..385e131
--- /dev/null
+++ b/_events/athens2015/agenda.md
@@ -0,0 +1,149 @@
+---
+layout: event_detail
+title: Agenda
+event: athens2015
+order: 10
+permalink: /events/athens2015/agenda/
+---
+
+Day 1
+-----
+
+*Tuesday, December 1*
+
+
+* 9.00 Breakfast
+* 10.10 Opening Circle
+* 10.40 **Where are we at today (in Debian)?**
+* 11.20 Break
+* 11.40 *Speed Geeking* (interactive project showcase)
+ - **Binary Transparency**
+ - **Tor Browser**
+ - **Bazel**
+ - **Guix/Nix**
+ - **F-Droid**
+* 12.35 What do you want to work on during the summit?
+
+ Participants are invited to identify 3 to 5 statements or questions
+ highlighting topics they'd like to work on at the meeting.
+
+ One topic per post-it. Then post-its are collectively clustered by
+ topic.
+* 12.50 Lunch break
+* 14.20 Working Sessions 1
+
+ Two rounds: 45-minute round + 10-minute round to check out one more
+ session (if desired)
+
+ - **Shared problems we can work on this week**
+ - **[Controlling the build environment]({{ "/events/athens2015/controlled-build-environment/" | prepend: site.baseurl }})**
+ - **Generalizing reproducible.debian.net continuous test system**
+ - **[Distribution/compiler bootstrapping and whole chain auditing]({{ "/events/athens2015/bootstrapping/" | prepend: site.baseurl }})**
+* 16:20 Break
+* 16.35 Working Sessions 2
+
+ One 45-minute round
+
+ - **[Advocacy: communicating benefits of reproducible]({{ "/events/athens2015/benefits/" | prepend: site.baseurl }})**
+ - **[Improving the documentation]({{ "/events/athens2015/improving-docs/" | prepend: site.baseurl }})**
+ - **[Making file system images reproducible (installer, live media)]({{ "/events/athens2015/system-images/" | prepend: site.baseurl }})**
+ - **[Improving the Glasgow Haskell Compiler]({{ "/events/athens2015/ghc/" | prepend: site.baseurl }})**
+* 17.30 Closing circle
+
+ Final round question: What is one thing you would like to work on or get
+ done tomorrow?
+
+* 18.00 Adjourn
+
+Day 2
+-----
+
+*Wednesday, December 2*
+
+
+* 9.00 Breakfast
+* 10.00 Opening Circle
+* 10.15 Working Sessions 3
+
+ Two rounds: 50-minute round + 10-minute round to check out one more
+ session (if desired)
+
+ - **RPM**
+ - **[diffoscope wishlist]({{ "/events/athens2015/diffoscope-wishlist/" | prepend: site.baseurl }})**
+ - **[Shared database of issues]({{ "/events/athens2015/issue-database/" | prepend: site.baseurl }})**
+ - **[Use cases for reproducible builds]({{ "/events/athens2015/use-cases/" | prepend: site.baseurl }})**
+* 11.30 Break
+* 12.15 **Skillshare**
+
+ Participants are invited to choose a skill they'd like to share.
+ Focused 1-3 person 30-minute conversations
+
+ - How to get reproducible buildroot for Fedora / What needs to be
+ done to get Arch Linux reproducible
+ - How to rebuild .debs from reproducible.debian.net
+ - How to do git (tag) signatures correctly (and verify them)
+ - How to chroot and mout on Linux without superuser privileges
+ - How to prove Gödel's First Incompleteness Theorem
+ - How to (I) mass bug file in Debian
+ - How to automate Jenkins configuration
+ - How to edit Zip archives
+ - How to build reproducibly in OS X
+ - How to replace binutils with an alternative toolchain
+ - How to fix timestamps issues to make builds reproducible
+ - How to set up a system to have "everything" go through Tor
+* 13.00 Lunch break
+* 14.00 Working Sessions 4
+
+ One 50-minute round
+
+ - **Becoming a diffoscope hacker**
+ - **[Communicating reproducible builds to users]({{ "/events/athens2015/communicating-with-users/" | prepend: site.baseurl }})**
+ - **[Post-event collaboration]({{ "/events/athens2015/post-event-collaboration/" | prepend: site.baseurl }})**
+ - **[Review of Debian .buildinfo file]({{ "/events/athens2015/debian-buildinfo-review/" | prepend: site.baseurl }})**
+ - **SOURCE\_DATE\_EPOCH**
+* 15.15 Closing circle
+
+ Final round question: What do you want to hack on?
+
+* 15.45 **Hacking Time**
+* 17.35 Closing circle
+
+ Final round question: What is one thing you would like to work on or get
+ done tomorrow?
+
+* 17.50 Adjourn
+
+Day 3
+-----
+
+*Thursday, December 3*
+
+* 9.00 Breakfast
+* 10.15 Opening Circle
+* 10.30 Working Sessions 5
+
+ One 50-minute round
+
+ - **[Advocacy: next steps]({{ "/events/athens2015/advocacy-next-steps/" | prepend: site.baseurl }})**
+ - **[Unsolved problems]({{ "/events/athens2015/unsolved-problems/" | prepend: site.baseurl }})**
+ - **[Next Reproducible Builds event]({{ "/events/athens2015/next-event/" | prepend: site.baseurl }})**
+ - **[What should be in a build info file?]({{ "/events/athens2015/buildinfo-content/" | prepend: site.baseurl }})**
+* 11.30 Break
+* 12.00 Hacking Time
+* 13.30 Lunch break
+* 14.30 Working Sessions 6
+
+ One 60-minute round
+
+ - **[Fundraising]({{ "/events/athens2015/fundraising/" | prepend: site.baseurl }})**
+ - **[Design an ideal reproducibility testing tool]({{ "/events/athens2015/reprotest/" | prepend: site.basurl }})**
+ - **Finishing Debian .buildinfo specification**
+ - **[Challenges with signed software]({{ "/events/athens2015/signed-software/" | prepend: site.baseurl }})**
+* 16.00 [Where from here?]({{ "/events/athens2015/where-from-here/" | prepend: site.baseurl }})
+
+ Participants are invited to write statements starting with "I Will"
+ (name of author required), "We should" and "Don't Forget" (name not
+ required)
+
+* 16.40 Closing Circle
+* 17.00 Adjourn
diff --git a/_events/athens2015/benefits.md b/_events/athens2015/benefits.md
new file mode 100644
index 0000000..8308e53
--- /dev/null
+++ b/_events/athens2015/benefits.md
@@ -0,0 +1,43 @@
+---
+layout: event_detail
+title: Communicating benefits of reproducible builds
+event: athens2015
+order: 40
+permalink: /events/athens2015/benefits/
+---
+
+*45-minute session on day 1*
+
+Some benefits have been written down on [reproducible-builds.org](https://reproducible-builds.org/docs/buy-in/) and the [Debian Wiki](https://wiki.debian.org/ReproducibleBuilds/About).
+
+What came during the discussion:
+
+ * Faster development times:
+ + Through caching of intermediate build products.
+ + In FreeBSD packages are rebuilt weekly and non-reproducible packages get reuploaded every time.
+ * Investigate whether the source changes are reflected in associated changes in the binary.
+ * Validation of cross compilers (slow arches can be cross compiled).
+ * Recreation of debug symbols at later times.
+ * Able to trace build while making sure that tracing didn't influence the build.
+ * Recognize changes made to the build output at run time (e.g. switching file content at runtime by evil kernel module)
+ * Gambling industry.
+ * Volkswagen scandal follow-up: proof that software running in the car is coming from the audited source.
+ * Three broad categories (afffected people):
+ + Software developers
+ + Distro developers
+ + End users
+ - Paranoid users
+ - Journalist using Tails
+ - Update deltas are smaller or don't exist in the first place
+ + Managers
+ - Trust fewer people (developers only push checksums and builder builds)
+ - Faster development times (through caching)
+ - Save money and time
+ - Accountability
+ - Counter argument for the argument free software is unreliable
+ * Myths and counter arguments:
+ + Timestamps, username, hostname in documentation etc are useful.
+ - That audit trail is not needed anymore with reproducible builds.
+ + Reproducible builds are hard and/or impossible.
+ - 19,000 packages are reproducible.
+ + Hard to check whether software is reproducible.
diff --git a/_events/athens2015/bootstrapping.md b/_events/athens2015/bootstrapping.md
new file mode 100644
index 0000000..41b190f
--- /dev/null
+++ b/_events/athens2015/bootstrapping.md
@@ -0,0 +1,70 @@
+---
+layout: event_detail
+title: Distribution/compiler bootstrapping
+event: athens2015
+order: 30
+permalink: /events/athens2015/bootstrapping/
+---
+
+*45-minute + 10 minute session on day 1*
+
+Problem: distributions use binaries from earlier releases to build their sources. This requires trust in existing binaries (cf. [Thompson attack](https://en.wikipedia.org/wiki/Backdoor_%28computing%29#Compiler_backdoors)).
+
+Toolchain bootstrap status
+--------------------------
+
+Nix, Guix: Toolchain provided by a binary archive containing GCC to bootstrap. Source versions noted, but not even automated.
+
+Guix: Has Scheme implementations of various tools (`wget` replacements etc.) required for bootstrapping to not have to rely on binaries. How feasible, scalable is that?
+
+Debian: Builds everything with maximum number of features, thus maximum number of build dependencies. The dependency graph has cycles of size 800, including stuff like Firefox even. So called *build profiles* (similar to USE flags in Gentoo) reduces this a lot; this is work in progress. Then we should be down to 120.
+
+Debian’s approach to bootstrapping: Not a single bootstrapping script, but rather sufficient meta-data in packages to allow bootstrapping, [rebootstrap](https://wiki.debian.org/HelmutGrohne/rebootstrap) project led by Helmut Grohne. Starting point is an existing minimal Debian, and then starts building a compiler from there. Eventual goal: Diverse Double Compilation of a whole distribution. This does not require varying compiler versions, but rather similar (or same) compiler versions wi [...]
+
+Diverse Double Compilation
+--------------------------
+
+Diverse Double Compilation can detect backdoors, unless they are in all used compilers.
+
+Problems:
+
+ * There are not many compilers to choose from (C++: only two free ones). Is it acceptable to use non-free ones here?
+ * Compiler source is not the only input (binutils, libc etc.)
+
+**Task**: Needs a definition of the features required from a minimal base compilation system (shells, Make, etc.), so that we can bootstrap one distribution on another.
+
+Compilers
+---------
+
+Other compilers, like GHC, rust, MIT Scheme: Requires specific recent versions of itself.
+
+**Task**: What is the most recent version of GCC that can be built with another C compiler?
+
+**Task**: What is the most recent version of GHC that can be built with another compiler, e.g. Hugs (which would be implemented in C)?
+
+One way out: GCC frontend, e.g. for Rust.
+
+Better examples:
+
+ * Guile: Comes with a C interpreter.
+ * JDK (not much of a problem, can be bootstrapped with GCJ)
+
+*Wish*: Compiler implementors would provide a easily executable rewrite-semantics for their languages, for bootstrapping. But likely far too much effort. One selling point would be that it also helps bootstrapping on new architectures.
+
+Certifcation for compilers: is there a way to certify compilers? Can we create a standard procedure for bootstrapping a compiler and providing a hash of a known good GCC 4.8 (+ `libc`, Make) binary, for example?
+
+Should we try to encourage languages:
+
+ - To have two diverse compilers?
+ - To have a compiler written in C (which can then be verified)?
+ - To have an interpreter written in another lanuage? (This may be easier than a compiler)
+ - To create a compiler ring (A compiles B compiles C compiles A)?
+
+**Task**: Investigate whether NetBSD can be fully diverse double-compiled.
+
+Summary
+-------
+
+Overall question: What are the benefits from complete bootstrapping from
+scratch? Anything besides the Thompson attack? Less binaries to trust! Cross
+compilation again, more important now.
diff --git a/_events/athens2015/buildinfo_content.md b/_events/athens2015/buildinfo_content.md
new file mode 100644
index 0000000..3378490
--- /dev/null
+++ b/_events/athens2015/buildinfo_content.md
@@ -0,0 +1,76 @@
+---
+layout: event_detail
+title: What should be in a build info file?
+event: athens2015
+order: 170
+permalink: /events/athens2015/buildinfo-content/
+---
+
+*50-minute session on day 3*
+
+**Absolutely necessary** "human intent"
+
+ - embedded certificates if needed (rpm + tor windows)
+ - source pkg. version
+ - source pkg hash (contents)
+ - source package name
+ - architecture (target) (GNU host)
+ - build instruction (deb-implicit)
+ - USE flags (gentoo). debian: build profile. build time configuration
+ - build-depends. Abstract description of some tool that (fully) defines
+ - Build-Depends. Source Name/version
+ - Build-depends. Source packages' HASH!!! (contents) complicated but worth it for D.D.C.
+
+*Center of the poster*
+
+ - order of pkg installation (deb-missing)
+
+*Going ahead, left half of the poster, from center to Too Specific-side*
+
+ - kernel version
+ - Architecture (build) (Bazel host)
+
+**Too Specific** "happenstance"
+
+ - state of filesystem
+ - host name
+ - username
+ - full env.
+ - default shell
+ - Build iteration #
+ - eye colour, height and hair length of the person who built the thing
+ - build path
+ - timestamp (`SOURCE_DATE_EPOCH`)
+
+Poster 2
+--------
+
+**Purposes of build info**
+
+ 1. document what pkg builder did
+ 2. reproduce build environment
+ 3. input to system to find minimum set req. for reproducibility
+ 4. fore debugging non-reproducibility
+ 5. forensics
+
+Misc.
+-----
+
+The Debian `.buildinfo` specification includes things across the spectrum.
+Build path and build architecture, for example, should not affect the outcome
+but is included.
+
+Hashes of the source (and build options) of dependencies are seen as more desirable than hashes of the binaries of dependencies, although Debian will probably continue to use hashes of binaries.
+
+It may be useful to put the fields that are required into the source package. E.g. “nethack requires build-path to be reproducible”
+
+Purposes of buildinfo:
+
+* Document what the package builder did
+ * Provide debugging non-reproducibility
+* Reproduce the build environment
+* Figure out the minimum amount of information necessary: as input to a system that finds the minimum required set.
+
+Must buildinfo be signed? Most people seem to think that we should recommend signing but not make it essential.
+
+Output will also be an optional thing in the results specification. Debian currently supply output hashes of packages. This can't be directly compared with another distribution's output, but the hashes can be used to find a specific package binary which can then be extracted and the contents compared.
diff --git a/_events/athens2015/communicating_with_users.md b/_events/athens2015/communicating_with_users.md
new file mode 100644
index 0000000..a09c7b2
--- /dev/null
+++ b/_events/athens2015/communicating_with_users.md
@@ -0,0 +1,70 @@
+---
+layout: event_detail
+title: Communicating reproducible builds to users
+event: athens2015
+order: 110
+permalink: /events/athens2015/communicating-with-users/
+---
+
+*50-minute session on day 2*
+
+Motivating questions
+--------------------
+
+ 1. What is the mechanism for publishing and sharing the results of reproducible builds?
+ 2. How do end users verify a reproucible build?
+ 3. What happens when verifiers can't agree on the result of a reproducible build?
+
+Prior art
+---------
+
+In GNU Guix, users can build a package by first building a container which only includes the inputs to the build, and then running the build in that container. There is an option to “challenge” a build, whereby users compare their results to other user-submitted results.
+
+It's easy for everyone to
+
+ * *Build*: re-build packages locally
+ * *Share*: share their results with other users
+ - Idea: it might be more efficient to share the hash of artifact along with the
+ signature of builder, instead of sharing the full entire artifact.
+ * *Challenge*: compare results with those of other users
+
+Currently, lots of packages are not deterministic, so this facility is used to _detect_ instances of non-determinism.
+
+Apt: `apt challenge` would hash locally-installed binaries and compare them to those published by Debian servers. It's difficult to do this securely: if you only trust one server then you can DoS it. If you use multiple servers then you need a voting scheme which may be arbitrary.
+
+One option: you have a CA-like authority that verifies reproducible builds. Users would have a pre-defined trusted CA list.
+
+Suggested primitives / APIs
+---------------------------
+
+Four APIs that would be useful:
+
+**Build info**: Standard for representing a reproducible build (debian build info, equivalent)
+
+**Rebuild tool**: Tool that given a “package spec” fetches the sources and rebuilds the package, outputting the hash of the build artifact
+correct versions of build tools must be available.
+
+One possible solution: insert the build tools in the source repo. Full source code history must be available or within some retention policy, if storage is a concern.
+
+**Binary transparency log**: every time Debian generates a package, they insert the build info and binary hash into the log. Multiple authorities (institutions or individuals, with diverse political affiliations and legal constraints) could verify these builds. If they lie, they might be detected by other authorities and their reputations would be compromised.
+
+The ownership structure of the log is important. If it's centralized, we end up with a single point of failure, or an authority that we cannot circumvent. We should prefer a decentralized log, for example the blockchain.
+
+**Reproducibilty policy**: people specify the requirements on the code that they run. Sample policies:
+
+ * If authorities agree then I accept the package, otherwise I verify it myself
+ * I don't care about verifiability
+ * I only accept a single authority
+
+Open question: What happens when verifiers can't agree on the result of a reproducible build?
+
+Open question: if I run a verification service as an individual user, I may not want to reveal that I am using (building). Can we allow users to do that, perhaps using Tor.
+
+A front-end would need to know various services to check against, validate the append-only log. The UI could tell you when your trusted authorities don't agree.
+
+⚠ There are different notions of reproducibility:
+
+ * being able to rebuild a package in practice (e.g. build tools and source code are available, but bit-by-bit equality of the result is not guaranteed);
+ * having bit-by-bit equality. This is what we usually mean by “reproducible builds”.
+
+⚠ We have to be careful about the terms we use to describe the verifiers. If we use the term “authority”, that implies that there is a small number of institutional actors that you end up trusting, and we might end up in the same state as right now. We should move towards a flat peer-to-peer model, where verifiers can be both individuals and institutions, and people are free to choose which verifiers they trust.
diff --git a/_events/athens2015/controlled-build-environment.md b/_events/athens2015/controlled-build-environment.md
new file mode 100644
index 0000000..6d161da
--- /dev/null
+++ b/_events/athens2015/controlled-build-environment.md
@@ -0,0 +1,92 @@
+---
+layout: event_detail
+title: Controlling the build environment
+event: athens2015
+order: 20
+permalink: /events/athens2015/controlled-build-environment/
+---
+
+*45-minute + 10 minute session on day 1*
+
+Testing that a piece of software is reproducible means having the ability
+to control the environment to perform variations that could later be found
+in the wild. A project could also decide to making a piece of software
+reproducible by specifying precisely in which environment it should be build.
+Both approaches basically require the same set of tools, it's just when that
+differs.
+
+
+Non-exhaustive list of variations: username, hostname, build path, timezone,
+cpu, locale, filesystem ordering
+
+Every project can approach differently:
+
+ - some projects want to set the same build environment for every developers
+ - other projects want different environments to produce same builds. In that case, need to test using different environments.
+
+For Debian:
+
+ - sbuild/pbuilder: unpack a minimal chroot, install dependencies, and build
+ - script called prebuild, doing build twice with different environments to find sources of non-determinism
+ - srebuild script using the list of packages involved in the build initially recorded in `.buildinfo files`. We can use snapshot.debian.org to recreate environment.
+ - on debian, different system has been setup 399 days in the future to check reproducibility
+ - some packages have valid-before, valid-after X.509 certificates
+ - no network access in the builds
+ - issue: libraries compiling optimisations depending on cpu. libgmp: `--enable-fat` option can disable this. Deciding which optimization to use on user side instead of build side.
+
+On FreeBSD:
+
+ - [poudriere](https://github.com/freebsd/poudriere)
+ - tool to setup environment using [jails](https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html)
+ - very easy for users
+ - can set hostname, timezone, user inside the jail, build path, network, fake kernel version
+ - only thing not possible to change from jail: faking the time
+ - lot of people use that to build because it's easy
+
+For single projects:
+
+ - can be easier to use VM
+ - VM: need a lot of trust in the VM, we can't yet reproducibly build images
+ - can use containers on Linux
+
+Qubes:
+
+ - does not capture yet the environment
+ - build with same user and path
+
+Google:
+
+ - build farm on Google internal network
+ - isolation not to enforce things, but avoid accidents
+ - bazel, sandbox
+ - with bazel, caching when building on the same machine
+ - not yet at reproducible cross-host and cross-user
+
+OS X:
+
+ - no jail, standard chroot
+ - problem: some standard apple tools broken in chroot
+ - no easy way to change hostname and username
+ - best approach at the moment, using VM
+ - macports: `LD_PRELOAD` to hide some files: 100% overhead
+ - Tor Browser: cross compiling from Linux using Apple SDK
+ - Homebrew: user relocatable installation, don't produce binary identical
+ binaries because of paths. sometimes grepping won't work
+
+Faking CPU can be tricky. One solution is to tell kvm to stop exposing the host CPU.
+
+disorderfs, implemented with FUSE, allow to test for issues tied to filesystem ordering. By default it will return results of readdir(3) backward. It could be modified to always returned readdir(3) in a sorted order to implement a normalized environment.
+
+Archive creation tools:
+
+ - GNU Tar has an option to do reproducible tarballs
+ - bsdtar not yet
+ - At Google, fixed: tar, zip, ar, rpm. Not yet upstreamed changes.
+ - lzma is threaded: result depends on number of cpu
+
+Things we could do:
+
+ - Fixing libarchive, and archive tools: sort files list, normalize permissions
+ - Improve freebsd jails: number of cpu, amount of memory
+ - Missing: tool to run the same thing twice in different environments
+ - Improve Linux containers: fake cpu
diff --git a/_events/athens2015/debian_buildinfo_review.md b/_events/athens2015/debian_buildinfo_review.md
new file mode 100644
index 0000000..8980746
--- /dev/null
+++ b/_events/athens2015/debian_buildinfo_review.md
@@ -0,0 +1,51 @@
+---
+layout: event_detail
+title: Review of Debian .buildinfo file
+event: athens2015
+order: 130
+permalink: /events/athens2015/debian-buildinfo-review/
+---
+
+*50-minute session on day 2*
+
+What we wanted to address:
+
+ * What should we have in the build info file?
+ * What currently affects the build but isn't documented?
+ * What explictily shouldn't affect the build and should we record that?
+
+We ran through the existing `.buildinfo` specification and found a lot of terms
+which meant different things to different people. “Architecture” is assumed to
+be the target architecture—and there is confusion between target and host
+(since we could be building a cross compiler package, which has a different
+build, host and target). Bazel also call the destination architecture the
+“host”.
+
+The `Binary` field is potentially useful but not necessary to reproduce; it
+lists intermediate stages to the actual build result (the set of `.deb` packages)
+
+josch pointed out that packages can have different source version and target
+versions, and the current field `Version` is not clear.
+
+HW42 suggested that checksums should be added to the dependency information.
+At the moment, on Debian, a package may be rebuilt by the reproducible builds
+CI system and produce a different result to before because of changes to its
+dependencies, so the package name, arch and version do not uniquely identify an
+exact dependency binary.
+
+Installation order of dependency packages doesn't *appear* to be recorded—the
+list of depedencies is in alphabetical order, and there are ways the
+installation order of dependency packages could affect the build environment.
+
+There are two camps here—either we fix the order (to make reproduction easier)
+or we randomize it (to pick up errors caused by installation order).
+
+A hash of the entire filesystem which is about to be used to build the system,
+after installation of dependencies, is the most generic record of the build
+environment and we don't record that. Should we? It will of course vary
+according to the filesystem used unless that is standardised.
+
+We also noted that the buildinfo file performs two functions at the moment—it
+is both a record of the environment used to build, and a specification for
+others. Is it sensible to keep both functions in the same file, or should we
+decide on one function? There will be some information which is common to both.
diff --git a/_events/athens2015/diffoscope_wishlist.md b/_events/athens2015/diffoscope_wishlist.md
new file mode 100644
index 0000000..8740084
--- /dev/null
+++ b/_events/athens2015/diffoscope_wishlist.md
@@ -0,0 +1,23 @@
+---
+layout: event_detail
+title: diffoscope wishlist
+event: athens2015
+order: 80
+permalink: /events/athens2015/diffoscope-wishlist/
+---
+
+*50-minute + 10-minute session on day 2*
+
+After reviewing what diffoscope is already able to do, here are some more ideas of what it could do:
+
+ - Write a wrapper around `diff` that strips out large identical chunks and only feeds in smaller chunks so that diffing can work on huge files. `diff` currently does not care about not supporting e.g. a million line long files because if your source code file is that large: you’re doing it wrong so diffoscope can have problems with huge diffs.
+ - Multithreaded/parallel processing.
+ - Better/smarter ELF diffing. Crazy idea, amongst others: use DWARF symbols to display the lines of code responsible for a given difference.
+ - Add a command line flag for “ignore profiles” removing differences that are not relevant or paths that can be ignored.
+ - Replace Open Build Service’s [pkg-diff.sh](https://github.com/openSUSE/build-compare) tool with diffoscope to allow better understanding of package differences.
+ - Sandboxed environment to secure diffoscope on untrusted input.
+ - Internal anchor links in the HTML report to be able to jump around. Typically from a file in a file list to its differences.
+ - Image comparisons ([GitHub does them right](https://github.com/blog/817-behold-image-view-modes))
+ - Hint system that provides suggestions on how to fix a problem.
+ - Have a hosted web service for doing the diffing (will require a sandbox).
+ - Start an embedded HTML server so that you can view diffing results coming in as soon as they are computed.
diff --git a/_events/athens2015/fundraising.md b/_events/athens2015/fundraising.md
new file mode 100644
index 0000000..6f864d8
--- /dev/null
+++ b/_events/athens2015/fundraising.md
@@ -0,0 +1,36 @@
+---
+layout: event_detail
+title: Fundraising
+event: athens2015
+order: 180
+permalink: /events/athens2015/fundraising/
+---
+
+*60-minute session on day 3*
+
+How can the money be strategically spent?
+
+ - people's time (grants, tasks, projects)
+ - meetings
+ - travel
+ - build resources (cpu time)
+ - Apple hardware
+ - hardware (not Apple)
+ - marketing & advocacy
+ - whitepapers advocacy for managers
+ - build infrastructure
+
+Questions and issues
+
+ - how do we allocate funds?
+ - transparency
+ - crowdfunding
+ - r-b legal body?
+ - how long?
+ - open source employee time
+
+Next Steps
+
+ - public call for proposals
+ - per-funder approach for funding request
+ - Cc list for proposal committee
diff --git a/_events/athens2015/ghc.md b/_events/athens2015/ghc.md
new file mode 100644
index 0000000..dbb365c
--- /dev/null
+++ b/_events/athens2015/ghc.md
@@ -0,0 +1,44 @@
+---
+layout: event_detail
+title: Improving the Glasgow Haskell Compiler
+event: athens2015
+order: 70
+permalink: /events/athens2015/ghc/
+---
+
+*45-minute session on day 1*
+
+Even before considering reproducible builds, [GHC](https://www.haskell.org/ghc/) has the following problems:
+
+Change in a function causes changes in packages using it due to heavy cross-module inlining (`.hi` files).
+It's the same API, but the ABI changes anyway. It's caused by intermediate
+format where names are invented, supposed to be unique. A global counter used
+for that. Using parallel compilation you get different numbers, sometimes
+ending up in interface files. GHC people are working on this because they want
+to get interface files stable too, even for partial builds. Stable binary files
+are a logical next step.
+
+Debian package for GHC and libraries can be built reproducibly, but using
+parallel mode. Other smaller changes exist, e.g. build path, debug sections.
+Debian works around these (using a fixed path for the build directory,
+predictable file names for temp files). Patches need review by other GHC
+developers before they can be merged (the Debian maintainer is also GHC
+developer).
+
+But even so Haskell packages on a user's system have to be updated all
+together.
+
+Possibly write a tool to renumber random numbers in object files to allow
+parallelization again.
+
+diffoscope supports diffing GHC interface files (`.hi`) (using GHC).
+
+OCaml has a similar problem (but perhaps less obvious).
+
+Discussion about rebuilds on Debian caused by Haskell ABI changes, then about other triggers for rebuilds, and associated waste of CPU time, and how to avoid that.
+
+OS X has different tmp directory path every reboot.
+
+Ways to get GHC to NOT include the path to temp files. e.g. pass in a source and build directory as arguments, make GHC only include VARIABLE plus relative paths (and variable replaced by debugger).
+
+Arch Linux observed changes in parallel builds in GHC, to investigate if they are fixed by Debian patches.
diff --git a/_events/athens2015/improving_docs.md b/_events/athens2015/improving_docs.md
new file mode 100644
index 0000000..e959bee
--- /dev/null
+++ b/_events/athens2015/improving_docs.md
@@ -0,0 +1,46 @@
+---
+layout: event_detail
+title: Improving the documentation
+event: athens2015
+order: 50
+permalink: /events/athens2015/improving-docs/
+---
+
+*45-minute session on day 1*
+
+Let's try to find aspects that are missing or could be improved in the
+documentation currently available on `reproducible-builds.org` website.
+
+ * Good/bad practices for an upstream, what should it be aware of?
+ (e.g. toolchain recommendations)
+ - *available*
+ * Checklist for developers
+ - *available*
+ * What about distro-specific documentation? Roadmaps for distributions
+ (step-wise: once you got to X you could do Y and so on)
+ - *partially written*: as many projects are making their own experience it's
+ hard to have good answers now.
+ * Documentation for non-free software toolchains and platforms that might not
+ be able to go for the bit-by-bit paradigma.
+ - *available*, at least basic ideas.
+ * Documentation for people that tried to reproduce a program but failed (being
+ that they get different output or the build is falling at all). What are
+ the next steps in this scenario?
+ - **missing**
+ * Step-by-step help with common problems (screencast + example by step)
+ - **missing**
+ * Index by tool in order to show you easily information/issues with/about it
+ and how to resolve them. “If you use this tool, these are the things you
+ need to think about”
+ - **missing**
+ * Contact opportunities/getting connected information on the website (mailling
+ list and/or IRC channel)
+ - *available*
+ * Slidedeck for someone running a class with motivation/pitfalls/solutions
+ - **missing**
+ * How do you set up an automated test environment
+ - **missing**
+ * Standard slide deck for university lectures (add exercises)
+ - **missing**
+ * Document how to contribute to the website
+ - **missing**
diff --git a/_events/athens2015/issue_database.md b/_events/athens2015/issue_database.md
new file mode 100644
index 0000000..719190c
--- /dev/null
+++ b/_events/athens2015/issue_database.md
@@ -0,0 +1,70 @@
+---
+layout: event_detail
+title: Shared database of issues
+event: athens2015
+order: 90
+permalink: /events/athens2015/issue-database/
+---
+
+*50-minute + 10-minute session on day 2*
+
+Use cases for sharing notes:
+
+ * For toolchain developers: what am I breaking.
+ * For leaf software developers: what's wrong with my code.
+ * For distributions developers: check out the status and *history* on other distributions and comparing.
+
+We should keep it streamlined, like keep it in git as the Debian project is currently doing.
+
+YAML seems to be cool for everybody.
+
+Issues:
+
+ - They can be fixed in different ways.
+ - They can be distro-specific.
+ - They can be implementation-specific.
+ - …
+
+It would be handy to have meta-issues.
+
+Regarding history:
+
+ - Link to example patches and keep old issues.
+
+Linking packages between distros:
+
+ - CPE (from CVE stuff)
+ - [distromatch](https://wiki.debian.org/Services/distromatch) (currently abandoned)
+
+Maintaining the notes:
+
+ - We need a format where we can separate “upstream” issues, distro-specific issues, distro-specific versions, etc.
+ - Different distros might have different way to fix issues.
+
+For Debian, moving remaining stuff from the wiki to the notes. (→ lamby)
+
+Possible format:
+
+ issue:
+ url:
+ description:
+ distro:
+ debian:
+ state: fixed
+ comment: |
+
+ package:
+ distros:
+ debian:
+ issues:
+ - issues1
+ - issue2 / free text # ← fixed issue
+ comments:
+ bugs: []
+ version:
+ freebsd:
+ version:
+ bugs: []
+ comments:
+ bugs: []
+ issues: []
diff --git a/_events/athens2015/next_event.md b/_events/athens2015/next_event.md
new file mode 100644
index 0000000..bcc9f61
--- /dev/null
+++ b/_events/athens2015/next_event.md
@@ -0,0 +1,39 @@
+---
+layout: event_detail
+title: Next Reproducible Builds event
+event: athens2015
+order: 160
+permalink: /events/athens2015/next-event/
+---
+
+*50-minute session on day 3*
+
+Frequency: for the next 2-3 events, every 6 months (e.g. April, November)
+
+Desired outcomes of the meeting(s) to guide brainstorming about location, size of group
+
+ - broadly: community building, following up on ongoing critical work. "Getting rpm to 85%!"
+ - specific outcomes for upcoming event to be identified reflecting on the outcomes of the Athens meeting, the *where from here* data
+
+Possible locations for upcoming meetings (criteria to consider: local hacker community/support, local logistics ally, visas, costs, easy to reach, accessible welcoming value-alligned venue)
+
+ - Portugal – akira had contacts, glad to explore opportunities
+ - Germany – Berlin, Hamburg
+ - Greece – Crete for community, local support, Manolis has contacts
+
+Next 2 meetings most likely in Europe to keep organizational side manageable and energy focused on work and content. For the following one (April 2017), considering opportunities outside of Europe as well (e.g. Canada/Montreal or US/Portland for support of local community)
+
+Side note: on names - Reproducible Europe Summit, Reproducible Americas Summit
+
+Emerging leadership to organize new meetings: ideally 2-3 organizers, who work in close connection to facilitators and local logistics contact
+
+Number of participants
+
+ - total: max 50-60
+ - up to 30 to be listed in a must-invite list + 20-30 new faces
+ - how to open to new participants? better than an open registration on a website: starting from asking the folks who will be in the to-be-invited list/ who came to Athens and know the model, to recommend others who they think would be great newcomers
+
+Possible advocacy opportunities at other events:
+
+ - contacts at 32C3 (December 2015) – Holger to ask the group what they think about it
+ - proposal and/or room at Fosdem 2017
diff --git a/_events/athens2015/post-event_collaboration.md b/_events/athens2015/post-event_collaboration.md
new file mode 100644
index 0000000..37b617e
--- /dev/null
+++ b/_events/athens2015/post-event_collaboration.md
@@ -0,0 +1,49 @@
+---
+layout: event_detail
+title: Post-event collaboration
+event: athens2015
+order: 120
+permalink: /events/athens2015/post-event-collaboration/
+---
+
+*50-minute session on day 2*
+
+benefits from collaboration
+---------------------------
+
+ - learning from each other
+ - not duplicating the work (not reinventing the wheel, like producing identical tools, debugging the same issues agains)
+ - larger userbase that gets exposed to reproducible builds (good for shaking out bugs)
+ - different communities coming together can help to think out-of-the-box
+ - sharing infrastructure
+
+what do we have
+---------------
+
+ - webserver (reproducible-builds) holger, lunar
+ - git repo there, too
+ - jenkins setup (debian, arch linux, coreboot, openwrt, netbsd, freebsd (fedora) (qubes)) profitbricks
+ - mailing lists
+ - twitter account (ReproBuilds)
+
+issues and challenges in collaboration (competative advantages)
+---------------------------------------------------------------
+
+ - specific project information too specific
+ - making clear what we are doing (making people not being unwelcome, though):
+ - "Reproducible builds are bit-for-bit identical"
+
+concerns that need to get addressed
+-----------------------------------
+
+ - use of infrastructure (emptiness of mailing lists)!?
+ - address problems when they occur
+
+misc
+----
+
+ - disentangling the debian and reproducible-builds things that are more general (non-Debian)
+ - every project has its own project mailing list and general questions go to the general one
+ - reproducible-athens -> reproducible-builds IRC
+ - bi-annual meeting!?; more open the next time
+ - session for organizing the next meeting, getting it distributed on more shoulders
diff --git a/_events/athens2015/reprotest.md b/_events/athens2015/reprotest.md
new file mode 100644
index 0000000..3fa2aeb
--- /dev/null
+++ b/_events/athens2015/reprotest.md
@@ -0,0 +1,158 @@
+---
+layout: event_detail
+title: Design an ideal reproducibility testing tool
+event: athens2015
+order: 190
+permalink: /events/athens2015/reprotest/
+---
+
+*60-minute session on day 3*
+
+Exercise in *README driven development*: think what the user documentation
+could be for the perfect tool to answer the question “How can I know if a piece
+of software is reproducible?”
+
+This tool is intended for developers who want to test whether their software is reproducible.
+
+Let's call it “*reprotest*”.
+
+Typical usage
+-------------
+
+ $ git clone https://github.com/foo/bar.git
+ $ cd bar
+ $ reprotest ./build.sh
+
+Exit status :
+
+ - `0` if reproducible
+ - `1` if not
+ - `2` in case of problems
+
+Provide useful information in both cases, links to reproducible documentation.
+
+Variations
+----------
+
+The default is to do all possible variations. The first thing tested will be
+the software in its current environment—with whichever tools the developer
+has in their normal environment. If it is shown to be reproducible there, it
+will attempt to try other environments similar to the systems which reported it
+unreproducible (e.g. reproducible.debian.net).
+
+To control which variations are being tested:
+
+ $ reprotest --keep-same=buildpath build.sh
+
+ $ reprotest --variations=date build.sh
+ # fail with something like:
+ # Sorry, date is not suported in direct mode
+ # (or do we want to use libfaketime?)
+
+ $ reprotest --variations=date --runner=virtualbox build.sh
+
+ $ reprotest --variations=date --runner=qemu --qemu-image=debian-sid.img build.sh
+
+ $ reprotest --variations=cpu,kernel,user,domain,date,filesystem make
+
+(filesystem will use disorderfs)
+
+Artifacts
+---------
+
+To control which artifacts will be compared at the end of the build:
+
+ # do not consider *.o file as files that need to match
+ $ reprotest --ignore=*.o build.sh
+
+ # only do a diff of *.deb files to determine if the thing is reproducible or not
+ $ reprotest --accept=*.deb dpkg-buildpackage
+
+Commands
+--------
+
+To compare different commands:
+
+ $ reprotest --command='make' --command='make CFLAGS=-g' --command='make CFLAGS=-O3'
+
+Project configuration file
+--------------------------
+
+If you have a `.reprotest` file in the current directory, you can run reprotest without
+any arguments to use the command and variations specified there:
+
+ $ reprotest
+
+By default, it will re-use the current system to run the build. To test with another toolchain:
+
+ $ reprotest --use-system-root=/path/to/chroot make
+
+To recreate another build:
+
+ $ reprotest --buildinfo=file.buildinfo --os=debian make
+
+ # try to guess which kind of buildinfo if --os is not specified
+ $ reprotest --buildinfo=file.buildinfo make
+
+If Debian allows all variations except build path then you can assess software is good for Debian by:
+
+ $ reprotest --profile=debian build.sh
+
+User configuration file
+-----------------------
+
+`~/.reprotestrc`:
+
+ default-runner = qemu
+
+ [qemu-runner]
+ default-image = ~/.reprotest/debian-sid.img
+
+Output
+------
+
+ $ reprotest --text=reprotest.txt => run diffoscope on all created files?
+
+ $ reprotest --html=reprotest.html
+
+ $ reprotest --junit=reprotest.junit (for jenkins) <- parsable output
+
+ # create reprotest-differences/build1/ and create reprotest-differences/build2/
+ $ reprotest --save-differences=reprotest-differences/
+
+ # create reprotest-differences.build1.tar.gz reprotest-differences.build2.tar.gz
+ $ reprotest --save-difference-archives=reprotest-differences
+
+ # create a json file with index and details about the test
+ $ reprotest --json=reprotest.json --save-differences=reprotest-differences/
+
+ # pass options to diffoscope
+ $ reprotest --diffoscope-options="--ignore=coverage/ --ignore=*.log"
+
+Options can be combined:
+
+ $ reprotest --html=reprotest.html --save-differences=reprotest-differences/
+
+If no output option is specified, plain text will be printed to the standard output.
+
+----
+
+Other possibilities:
+
+Run build twice, reproducing `$DEFAULT` set of information from build environment:
+
+ $ reprotest make
+
+Run build once, reproducing `$DEFAULT` set of infomation from `xxx.buildinfo`:
+
+ $ reprotest --buildinfo=bash_amd64.buildinfo make
+
+Run build once, reproducing fields `buildpath`, `username` from `bash_amd64.buildinfo`:
+
+ $ reprotest --reproduce=buildpath,username --buildinfo=bash_amd64.buildinfo make
+
+Check that `*.buildinfo` have the same result hash, find all the fields that
+have the same value across all files, reproduce those common fields, then run
+build once, and check if output has same hash:
+
+ $ reprotest --buildinfo=1.buildinfo --buildinfo=2.buildinfo --buildinfo=3.buildinfo make
diff --git a/_events/athens2015/signed_software.md b/_events/athens2015/signed_software.md
new file mode 100644
index 0000000..9207d9d
--- /dev/null
+++ b/_events/athens2015/signed_software.md
@@ -0,0 +1,79 @@
+---
+layout: event_detail
+title: Challenges with signed software
+event: athens2015
+order: 200
+permalink: /events/athens2015/signed-software/
+---
+
+*60-minute session on day 3*
+
+Current status:
+
+ - signed binaries
+ - NetBSD: source repo
+ - Tor: source signed (git tags)
+ - Tor Browser: signed binaries (repro), including windows binaries, instruction how to strip signature to compare built binary
+
+Who signs:
+
+ - Tor, Tor Browser:
+ - people allowed to sign source
+ - others ("builders") allowed to sign binaries
+ - different keys
+ - Windows, OSX - signatures verified by OS while installing the package
+ - distributions - public key for all the packages
+ - Debian: repository metadata signed (including package hashes), not the packages
+
+Documentation:
+
+ - provided over HTTPS
+ - ship in the packages (Debian)
+
+Signing key storage:
+
+ - Firefox auto updater: signed updates
+ - Tor Browser signing keys:
+ - sources
+ - firefox updates
+ - Windows, OS X
+ - binaries (packages)
+ - most of them are subkeys of master keys (stored offline)
+ - FreeBSD: key on build machine, user need to manually verify and add the key
+ - Guix: similar to FreeBSD - by default build locally, if you want to use ready binaries, you need to verify and configure the key
+
+Why and what next:
+
+ - signed binaries: for mirroring
+ - Guix: build locally and compare with mirrored
+ - Nix: plan to use multiple signatures on binaries and trust only one signed by at least N of M trusted set
+ - P2P for comparing binaries with others and download from nearest (if other trusted parties reports the same binaries)
+
+Threat model:
+
+ - build system compromise detection
+ - paper about update process attacks
+ - in Debian - developer compromise (because they are building the packages and uploading binaries)
+
+binaries transparency log:
+
+ - append only log with assertions that "developer X built reproducibly package
+ Y (with source hash) and the result binaries are Z (with such hash)"
+ - user can download that assertions and expect at least few of them to trust
+ the binaries
+
+
+`curl | bash` is almost the same as downloading `something.tar.gz` and compiling it—you still haven't verified that the code isn't modified and/or malicious.
+
+Source code signing is for accountability. And makes code review meaningful—you may make sure exactly what code was audited.
+
+
+GitHub might introduce interface for signaling the code is signed to encourage developers.
+
+
+Status of verification of different paths:
+
+ - binaries → users: mostly solved
+ - source pkgs → binary packages → reproducible builds
+ - developer → source code (tarballs/git) → mostly not solved currently, only few projects sign their code
+ - code auditing - also not solved problem
diff --git a/_events/athens2015/system_images.md b/_events/athens2015/system_images.md
new file mode 100644
index 0000000..75a115a
--- /dev/null
+++ b/_events/athens2015/system_images.md
@@ -0,0 +1,26 @@
+---
+layout: event_detail
+title: Making system images reproducible
+event: athens2015
+order: 60
+permalink: /events/athens2015/system-images/
+---
+
+*45-minute session on day 1*
+
+Two problem areas:
+
+ - Building installation media reproducibly (e.g. iso9660, squashfs, ubifs, ...).
+ - Building base images reproducibly (e.g. EC2 AMIs).
+
+Images are built in two ways:
+
+ - Using a filesystem builder tool such as `genisoimage` or `mksquashfs`. It's not clear if these are entirely deterministic today, but if not, it's probably easy to make them deterministic.
+ - Mounting a filesystem (either a *loopback* image, or inside a VM) and then running the installer (e.g. `nixos-install`). This is likely hard to make deterministic, since e.g. we really can't control the order in which the kernel allocates blocks. But we could unpack the image generated in this way and then use the first method to generate a deterministic image.
+
+Other problem: filesystems like *ext4* contain various timestamps like the last mount time. *ext4* apparently also has a random seed value used for directory entry hashing. These need to be set to a fixed value.
+
+Conclusions:
+
+ - We need to check/ensure that command line tools for image generation (like `mksquashfs`) are deterministic.
+ - diff support for filesystem images would be nice. Maybe add to diffoscope?
diff --git a/_events/athens2015/unsolved_problems.md b/_events/athens2015/unsolved_problems.md
new file mode 100644
index 0000000..fb82853
--- /dev/null
+++ b/_events/athens2015/unsolved_problems.md
@@ -0,0 +1,28 @@
+---
+layout: event_detail
+title: Unsolved problems
+event: athens2015
+order: 150
+permalink: /events/athens2015/unsolved-problems/
+---
+
+*50-minute session on day 3*
+
+* time machines service (like snapshots.debian.org)
+ + distros should check out and investigate this
+* infrastructure to host .buildinfo
+ + DEBIAN: open a bug against ftp.d.o
+* durable service hosting
+ + thinking, dreaming and look for funding
+* add reproducibility aspects to GNU/Apache/etc software policies
+ + reach out of them
+* write "random environment" tool
+ + write it
+* certificates expiring in testsuites, etc
+ + patches?
+* build paths
+ + research? stripping tool?
+* core dumps from VM-heavy software (e.g. emacs, smalltalk, etc)
+ + research
+* profile-guided optimisation
+ + investigation
diff --git a/_events/athens2015/use_cases.md b/_events/athens2015/use_cases.md
new file mode 100644
index 0000000..44d9916
--- /dev/null
+++ b/_events/athens2015/use_cases.md
@@ -0,0 +1,39 @@
+---
+layout: event_detail
+title: Use cases for reproducible builds
+event: athens2015
+order: 100
+permalink: /events/athens2015/use-cases/
+---
+
+*50-minute + 10-minute session on day 2*
+
+Use cases & success stories for build reproducibility:
+
+# Benefits
+
+ - Google: Confidence that what runs in production is actually what it is supposed to be
+ - Tor: Reduces pressure on single developer in control of the signing keys, helps against powerful adversaries
+ - Reproducible builds reduce developers' risk of being forced by law enforcement into creating malicious binaries
+ - Google: Build reproducible allows cache sharing and increases build speed tremendously (99% cache hits, associated with actual $$$ value), simplifies debugging because builds can be re-done and discrepancies easily discovered
+ - F-Droid: Reasonable easy secure release build process, builds can be easily verified with different machines. This increases confidence in the apps. Even for closed source apps, this allows developers to verify that the copy on Google Play is the same than you intended it to be.
+ - NixOS: Ability to have decentralized continous build system, build infrastructure can be distributed. Tests are a big topic, because they're not always reproducible; re-running tests can possibly be avoided if the binaries are exactly those that have previously been tested. Reproducibility enables purely functional package management, which avoids implicit dependecies (e.g. on the environment).
+ - Debian: Reproducible builds enable small delta updates, particularly if there is no delta. If toolchain changes don't change the binary re-testing can be avoided and changes can be reviewed.
+ - MacPorts: Reproducibility can provide confidence that a build on a user's machine produces what was intended by the packager; this reduces the support burden.
+ - Core Boot (bootloader) & Seabios: gain assurance of what's running at the lowest layers of your stack, and it runs in system management mode so it has full access.
+ - Reproducibility can be a legal requirement for some software (e.g. gambling or voting [citation needed])
+ - Reproducibility allows verification that the binary actually corresponds to the source code.
+ - Signing Code is just as secure as your key management, but key management is hard. Reproducibility can improve that.
+ - iOS Apps are encrypted by Apple, so you cannot easily verify that what Apple distributes is actually what the developer wanted.
+ - Third parties should be able to verify source <-> binary correspondence. This could be offered as a service for companies or done by volunteers who would then certify that a binary correspond to the source.
+ - Companies with long product cycles want to be able to bit-by-bit reproduce a binary in ten years time and heavily care about binary delta size. This allows to avoid storing the build results for the duration of the product cycle.
+
+# Categories of Benfits
+
+ - Financial Benefits
+ - Security Benefits
+ - Reduction of Responsibility on Single Developers
+ - Infrastructure Benefits
+ - Reduction of External Trust
+
+Putting this on reproducible-builds.org should be probably be done by categorizing it by target audience, i.e. benefits for users, for developers, for companies.
diff --git a/_events/athens2015/where_from_here.md b/_events/athens2015/where_from_here.md
new file mode 100644
index 0000000..c1f00f4
--- /dev/null
+++ b/_events/athens2015/where_from_here.md
@@ -0,0 +1,191 @@
+---
+layout: event_detail
+title: Where from here?
+event: athens2015
+order: 210
+permalink: /events/athens2015/where-from-here/
+---
+
+> Participants are invited to write statements starting with “I Will”, “We
+> should” and “Don't Forget”. Names have been omitted from the website.
+
+I will…
+-------
+
+ - I will make OpenWrt more reproducible
+ - I will make more coreboot payloads reproducible
+ - I will push squashfs patches upstream
+ - I will share a report to my fellow students back to the uni so maybe I can get them interested
+ - I will write a deign doc for different types of reproducibility + build info files
+ - I will upload koji to Debian
+ - I will make it easier to use Nix's –repeat/--check flags with diffoscope
+ - I will finish wiki content migration
+ - I will add tests to diffoscope image diff patch + resubmit
+ - I will make reproducible packages for Qubes OS
+ - I will make Hydra do repeated builds for NixOS
+ - I will start the “share the issues” database
+ - I will improve the code behind reproducible.d.n to test better other project
+ - I will send a r-b trip report to an appropriate FreeBSD mailing list
+ - I will write aor solicit a r-b article for the FreeBSD journal
+ - I will submit a r-b talk to BSDCon and/or other BSD conferences
+ - I will document reproducibility policy/mechanisms in the Nix pkgs manual
+ - I will send a report to the nix-dev mailing list
+ - I will update wtherpad with stuff I have done
+ - I will post my analysis of diffoscope “Too much info for diff” errors
+ - I will bring wip FreeBSD kernel reproducible patch into the tree
+ - I will document how to contribute to r-b.org website
+ - I will contact universities around my place to discuss r-b in CS curriculum
+ - I will cut a new diffoscope release
+ - I will follow upon getting ftp.master (debian) to accept & distribute .buildinfo files
+ - I will contact upstream tracker about reproducible builds
+ - I will work on reporting reproducibility in ccache, waf
+ - I will set up continuous reprodubility reports on Baserock
+ - I will upstream reproducibility fixes for NetHack
+ - I will continue to verify Debian results
+ - I will continue looking for unreproducible packages in Debian and patch them if I can
+ - I will continue looking at untagged non-repro. Packages in Debian and tag issues I recognize
+ - I will look into parsing ELF files as containers in diffoscope
+ - I will send `SOURCE_DATA_EPOCH RPM` patch pull request
+ - I will implement Qubes OS testing for jenkins.d.n
+ - I will report my srebuild experiment to the ML
+ - I will try to get some buildinfo for Qubes
+ - I will start working on making pkgsrc build reproducibly
+ - I will continue working on NetBSD to build reproducibly
+ - I will report to NetBSD about the summit
+ - I will report on the outcome of r-b Athens 2015 to macports-dev@
+ - I will implement `SOURCE_DATE_APOCH` support/tarball timestamp fixes in MacPorts (using `findnewest(1)`)
+ - I will figure out how to get a reproducibility patch into zipalign
+ - I will try to get some Googles to work on Bazel-on-Debian
+ - I will tell my co-workers that there is actually interest in making builds reproducible
+ - I will eat less on the next conference I go to
+ - I will work on reprotest
+ - I will take this Sunday off
+ - I will get RPMs tested by the end of 2015
+ - I will cleanup the jenkins.d.n. codebase so others can jump in more easily
+ - I will work a funding with Ed & Chris
+ - I will sort my ToDo
+ - I will write a blog post on Bazel website
+ - I will write a report to my team
+ - I will continue improving s(re)build
+ - I will not use `__DATE__`
+ - I will write a Tor blog post about the meeting
+ - I will look closer at Diverse Double Compilation
+ - I will upstream GHC patches
+ - I will investigate how possible it is to have the next meeting in Lisboa or elsewhere in Portugal
+ - I will make Qubes OS RPM build using the same tools as Fedora
+ - I will work on the reproducible builds to make them portable
+ - I will work on the FreeBSD package building tools to make them reproducible
+ - I will continue making Arch Linux reproducible and extend the pipeline and toolchain
+ - I will inform the Arch linux community about this event and progress
+ - I will continue contributing to cross distribution tools for reproducible builds
+ - I will get myself an account on alioth.d.o (issue database)
+ - I will email the GNU & Guix hackers to report back
+ - I will push for reproducibility in the GNU coding standards, and for repro. fixes
+ - I will start a discussion on how to sign code in GNU Guix
+ - I will email Holger to set up Guix on the ProfitBricks machines
+ - I will do a repro talk in a hackerspace
+ - I will report back to coreboot and OpenWrt
+ - I will inform Fedora community about this event
+ - I will keep the Fedora reproducible machinery updated, and working
+ - I will help upstream patches to RPM, cpio, gcc etc.
+ - I will help get packages in Fedora
+
+We should…
+----------
+
+ - We should invite key people from Fedora's release/build team
+ - We should push the idea rep. Into universities
+ - We should add source-sha256 to .deb and dpkg-buildpackage
+ - We should get buildinfo files in Debian already and fix dpkg
+ - We should have another rb meeting to share our progress
+ - We should find a simple way of signing each commit in Guix
+ - We should automate the way we compare the binaries between build servers and users in Guix
+ - We should attract more projects to work on reproducible builds
+ - We should have another reproducibility summit
+ - We should have a cross-distro wiki/database of common reproducibility issues
+ - We should find hardware sponsors so we can have multiple servers building packages so we can compare them
+ - We should have another reproducible meeting IRL
+ - We should organize another rb event
+ - We should encourage upstreams and mantainers to sign their source code
+ - We should hold another R.B. summit in about 6 months
+ - We should meet way more often than the proposed every 6 months
+ - We should actively invite Fedora people
+ - We should have another r-b summit (in NA)
+ - We should have publicly documented r-b build resources (hardware/ CPU time)
+ - We should invite OpenBSD to the next summit
+ - We should prepare flyers for FOSDEM
+ - We should decide how to get this shared database of issues running
+ - We should publish a buildinfo specification
+ - We should ship a “reproducible” debian subset as a suite
+ - We should develop buildinfo comparator tools. input: multiple .buildinfo w/ some out put artifacts. output: “these artifacts are reproducible when X & Y vary”
+ - We should develop clear stories for getting activists & civil liberties folks excited about r-b
+ - We should investigate reproducible cross-building e.g. freebsd on debian & viceversa
+ - We should write a cross-distro .buildinfo “translator”
+ - We should make reproducible builds the norm – also upstream
+ - We should continue to work on getting buildinfo into the debian archive
+ - We should make it easy for upstreams to check for reproducibility (e.g. make, waf integration)
+ - We should create tools for making reproducibility visible to users
+ - We should invite toolchain people from OpenBSD & DragonflyBSD (choose carefully!)
+ - We should have r-b whitepapers (for mgrs)
+ - We should commit publicly to r-b efforts (on mailing lists for example)
+ - We should have another reproducible builds summit
+ - We should keep in touch and share knowledge on the solutions and tools to solve reproducibility issues
+ - We should invite OpenSUSE at next meeting
+ - We should encourage more users to reproduce builds
+ - We should think about multi-sigs for reprod.software
+ - We should encourage source code signing
+ - We should get more Fedora/rpm people on board
+ - We should have another summit
+ - We should compare isues resulting from buildsystems (was on post-it)
+ - We should increase adoption of findnewest
+ - We should finish use case docs telling companies/managers why investing in r-b is a good thing
+ - We should work on getting tarbaV timestamp clamp support implemented upstream
+ - We should do this again
+ - We should figure out how to make Bazel interact with Debian better
+ - We should stay synchronized via mailing list
+ - We should have another reproducible builds conference
+ - We should add `SOURCE_DATE_EPOCH` to LLVM
+ - We should get (more) Fedora, Suse, Microsoft, Apple, Twitter, Facebook, Oracle people involved & to the next meeting
+ - We should write a blog post and a post to debian-devel-announce @ l.d.o
+ - We should have more meetings
+ - We should make software (esp. compilers) bootstrappable (DCC)
+ - We should invest time in tools that everybody is benefitting from
+ - We should have a follow-up meeting (face-to-face)
+ - We should have another reproducible builds meetup
+ - We should have a monthly meeting in IRC that is moderated
+ - We should really have a cross distribution exchange about patches and infos to not dupllicate efforts
+ - We should hold another r-b meeting!
+ - We should contribute to the shared issue database
+
+Don't forget…
+--------------
+
+ - Don't forget to take a stab and try pushing patches from Debian elsewhere too
+ - Don't forget to invite OpenSuse and Fedora/RM people next time
+ - Don't forget to send some practical details pior to event e.g. at least be @ “x” at “y” am a week before
+ - Don't forget to confirm hotel sponsorship!
+ - Don't forget to buy stock in 3M & sharpie
+ - Don't forget to invite Fedora people to the summit (CentOS, SL, OpJ, SUSE, gentoo)
+ - Don't forget about documenting how different projects are regarding r-b
+ - Don't forget we need lots of Internet
+ - Don't forget to invite `xorriso` upstream
+ - Don't forget to invite OpenSuse people next time
+ - Don't forget to invite cloud (e.g. docker, rocket) people next time
+ - Don't forget to solve verification of multiple identical builds by users
+ - Don't forget to thank Holger, Lunar, Gunner & all organizers & facilitators
+ - Don't forget updating r-b.org website
+ - Don't forget to build a database of non-deterministic tools and workarounds
+ - Don't forget thanking the organizers & sponsors
+ - Don't forget to invite people familiar with r-b on Windows
+ - Don't forget to invite Facebook/Buck team
+ - Don't forget that events like this need interwebs
+ - Don't forget to have stable WLAN at the next meeting
+ - Don't forget to invite Apple folks
+ - Don't forget to invite Microsoft folks
+ - Don't forget about addressing installation images creation reprod.
+ - Don't forget to define a clear threat model for reproducible builds so we can articulate by how much they raise the bar
+ - Don't forget to invite more people from industry (FB, Intel?, Twitter) and possibly academia
+ - Don't forget to bring a powerful router or two to the next event
+ - Don't forget to add to the website any new projects used in the real world that derive an articulable and clear benefit from reproducible builds
+ - Don't forget to communicate between projects
+ - Don't forget to keep thinking about how to reduce the set of bootstrap binaries
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/reproducible/reproducible-website.git
More information about the Reproducible-commits
mailing list