[reproducible-website] 01/01: berlin-summit: add (unverified) pads from riseup, without interlinks yet
Holger Levsen
holger at layer-acht.org
Tue Mar 7 15:48:30 UTC 2017
This is an automated email from the git hooks/post-receive script.
holger pushed a commit to branch master
in repository reproducible-website.
commit 04ca865a2485fac493bd2c9e2c2202effb4d744e
Author: Holger Levsen <holger at layer-acht.org>
Date: Tue Mar 7 16:48:24 2017 +0100
berlin-summit: add (unverified) pads from riseup, without interlinks yet
Signed-off-by: Holger Levsen <holger at layer-acht.org>
---
_events/berlin2016.html | 1 +
_events/berlin2016/2017lookahead.md | 347 +++++++++++++++++++++
_events/berlin2016/Gettext.md | 30 ++
_events/berlin2016/RPM.md | 65 ++++
_events/berlin2016/RPMII.md | 75 +++++
_events/berlin2016/SOURCE_PREFIX_MAP.md | 34 ++
_events/berlin2016/agenda.md | 187 +++++++++++
_events/berlin2016/agendabrainstorming.md | 265 ++++++++++++++++
_events/berlin2016/binarytransparency.md | 9 +
_events/berlin2016/binarytransparencyII.md | 55 ++++
_events/berlin2016/bootstrapping.md | 283 +++++++++++++++++
_events/berlin2016/bootstrappingII.md | 35 +++
_events/berlin2016/buildinfofiles.md | 84 +++++
_events/berlin2016/crossdistro.md | 80 +++++
_events/berlin2016/diffoscope.md | 64 ++++
_events/berlin2016/diffoscopedebug.md | 15 +
_events/berlin2016/documentation.md | 126 ++++++++
_events/berlin2016/documentationII.md | 164 ++++++++++
_events/berlin2016/documentationIII.md | 36 +++
_events/berlin2016/embedded.md | 35 +++
_events/berlin2016/enduserpolicies.md | 131 ++++++++
_events/berlin2016/gpl-compliance-20161214.md | 69 ++++
_events/berlin2016/reprobuildsdefinitionII.md | 51 +++
_events/berlin2016/reproduciblebuildsdefinition.md | 79 +++++
_events/berlin2016/reprotest.md | 53 ++++
_events/berlin2016/reusableimages.md | 56 ++++
_events/berlin2016/securegit.md | 28 ++
_events/berlin2016/stateofreproduciblebuilds.md | 64 ++++
_events/berlin2016/testinfrastructure.md | 84 +++++
_events/berlin2016/usecases.md | 70 +++++
_events/berlin2016/userverification.md | 61 ++++
_events/berlin2016/whatelse.md | 78 +++++
32 files changed, 2814 insertions(+)
diff --git a/_events/berlin2016.html b/_events/berlin2016.html
index 5e9f0c1..ffe50c9 100644
--- a/_events/berlin2016.html
+++ b/_events/berlin2016.html
@@ -56,6 +56,7 @@ event_summary: Three day follow-up workshop to Athens 2015 to continue and grow
<div class="eight columns text">
<p>
<ul>A number of reports have been published:
+ <li><a href="{{ "/events/berlin2016/agenda/" | prepend: site.baseurl }}">Meeting agenda and complete minutes</a></li>
<li><a href="/files/ReproducibleBuildsSummitIIReport.pdf">Report by Aspiration</a></li>
<li>by <a href="https://gnu.org/software/guix/news/reproducible-build-summit-2nd-edition.html">Ludovic Courtès, John Darrington and Ricardo Wurmus from the GNU Guix project</a></li>
diff --git a/_events/berlin2016/2017lookahead.md b/_events/berlin2016/2017lookahead.md
new file mode 100644
index 0000000..a6614bc
--- /dev/null
+++ b/_events/berlin2016/2017lookahead.md
@@ -0,0 +1,347 @@
+---
+layout: event_detail
+title: 2017lookahead
+event: athens2015
+order: 310
+permalink: /events/berlin/2016/2017lookahead/
+---
+
+1)
+ADVOCACY / OUTREACH / POLICY / EDUCATION
+
+* Documentation
+
+** teaching people to write reproducible code
+** SOURCE_PREFIX_MAP spec done
+** document all indirect highly valuable side-effcts of reproducible-builds
+
+* policy & law
+
+** uk demands reproducible firmware by law from HUAWEI
+** china asks the same from cisco
+
+* outreach
+
+** reproducible summit 3 2017
+** more talks at conferences around the world
+** reproducible hacking sprint 2017 (hackotlaw)
+** whitepapers and academic research
+** explain r-b to my grandmother/grandparent/grandchild in 5 sentences
+** all conferences have r-b tracks
+** start outreach to embedded device manufacturers
+** "reproducibility" is discussed as a new aspect of software trust (e.g., in security/privacy circles)
+
+* distro specific
+
+** debian-policy packages should be reproducible
+
+
+* generic/all distro
+
+** members from all distros
+** all distro package managers know about reproducible builds
+** post list of funded reproducibility projects
+
+
+* upstream/elsewhere
+
+** shouting loudly to upstreams
+** interest outside floss projects (closed software, internal development)
+** we will have convinced industry reproducibility is important
+** "ecosystem janitor team": group to make sure upstream sources remain available & mirrored with checksum
+** collaboration between industry and community much more significant
+** google chrome is reproducible and user verifyable
+** upstreams should be encouraged to issue a statement about reproducibility of their systems
+
+
+* misc
+
+** get as many people supporting bootstrapping efforts as we have reproducible people now
+** reproducible builds is explained in CS courses
+** we have a logo
+
+2)
+COMMUNITY / DOCUMENTATION
+
+COMMUNITY
+
+** meetings
+- regular 2-month IRC/voice meeting
+- more reproducible builds cross-project in person meetings
+- small 3-5 person hack sessions targeting specific goals
+** network tooling/services
+- a community of “rebuilers”(?) publishing logs about rebuilds exists
+- central webservice for submitting/retrieval of =.buildinfo= files
+** untitled column
+- more embedded dev work in the community
+** collaboration
+- =notes.git= will be more widely shared among distros
+- have more reproducibility teams in other distros
+- cross-distro outreach
+
+DOCUMENTATION
+** reproducible-builds.org
+- move content from debian pages to r-b.org
+- common place for all repro builds talks that everyone uses
+- there will be a “get involved” section
+- common (cross-distro) =.buildinfo= format specification written
+- blog planet/aggregator
+- we built a standard base for =.buildinfo= files
+- all cross-project tools documented not in specific projects only
+** projects or distributions
+- fedora reproducible docs on how to reproduce builds
+- produce a template for projects that wish to make a public statement about reproducibility
+- link to Nix docs from r-b.org
+- improved RB-related doc on Bazel website
+- how to attach signatures without disrupting reproduce? guidelines for packagers.
+** untitled columns
+- searchable database of reproducibility issues (e.g. manpages)
+- examples of non-reproducibility problems explained (3-4 package examples — what did it cause?)
+- the FAQ section will be full of tips on how to use various tools in a reproducible way
+- Encyclopedia for working around common non-repro issues
+- index collection with repro issues and solutions with search
+- reproducible docs as manpages
+- HOWTO about creating reproducible packages
+- teach people how to easily build and test existing software
+- document setting up tests.r-b.org type infrastructure
+
+
+3)
+COVERAGE / UPSTREAMS
+
+common
+------
+
+- upstream projects adopting SOURCE_PREFIX_MAP
+- reproducibility stats collected and reported (for debian, freebsd, macports, openwrt/lede, coreboot, netbsd, f-rdoird, arch linux, etc)
+- upstream git repos pass __???___ commits after cutoff date
+- reproducible iso images
+- all distros publish a statement about reproducibility
+
+freebsd
+-------
+
+- reproducible base system 100%
+- freebsd packages 90% reproducible by default (by count of pkgs)
+- all reproducible build options on by default
+- expectation for reproducibility understood by freebsd committers
+
+other distros
+-------------
+
+- macports will be 50% reproducible by count of pkgs
+- get gentoo on board!
+- more distros and FLOSS OSes join reproducible builds
+- OpenWrt & lede to 90% RB
+- prorpietary software incorporating reproduciblity
+- first 100% reproducible OS (with packages too)
+- reproducible pkg src packages
+
+RPM-based
+---------
+
+- support for `.buildinfo` in necessary tools
+- common discussion space for sharing problems and solutions
+- some simple RPM pkgs already reproducible
+- tools to reproduce
+
+guix
+----
+
+- GNU Guix will have measurements of pkg reproducibility
+- GNU Guix will have fixed repro issues in core packages: guile, python, gcc
+
+debian
+------
+
+- debian unstable is 95% reproducible
+- maintainers WANT to make reproducible debs
+- `.buildinfo` in archive
+- block debian testing migration on reproducibility regressions
+
+arch linux
+----------
+
+- write documention
+- tools for users to verify reproducibility
+- 100% reproducible core repo
+
+NixOS
+-----
+
+- reach milestone: make NixOS minimal ISO (+al deps) reproducible
+- Hydra (CI): graph or reproducibility progress
+- write nixpkgs documentation
+- investigate reproducibility for OSX in nixpkgs
+- nix: allow users to configure desired trust level (i.e. "wont only want only binaries builtby N out of K builders)
+- provide a verifiable bootstrap chain in nixpkgs going back ~10 years
+
+4)
+HARDWARE / EMBEDDED
+
+## Hardware
+- How can we improve trust in hardware?
+- Open Hardware Specs
+- Reproducible RISC-V implementation on FPGA
+- Where are reproducible/verifiable CPUs/microchips?
+- Reproducible HDL synthesis deemed feasible
+- Will have built/ported a free system to OpenRISC
+- How do we improve trust in our networking hardware?
+
+## Firmware
+- Binary blobs are evil – how do we get more open source firmware?
+- Reproducible OS images
+- Tool to generate reproducible image
+- How can end-users verify their firmware?
+- Can we convince companies to open source firmware?
+- Can we have firmware audits with checksums by independent third parties?
+- We have more Laptops supported without Management Engine
+
+## Internet of Things
+- We will have first devices with >= 50% reproducible software
+- Security updates for IoT devices will be a thing
+- There will be massive IoT botnets
+- Governments should force IoT manufacturers into maintenance!
+- Devices should be sold with clear maintenance period labels
+- Yocto/OpenEmbedded builds provide `.buildinfo` & are reproducible
+
+## Manufacturing
+- Convince manufacturers to give out reproducible firmware
+- Start conversations with vendors over benefits of reproducibility
+- Talk to OEMs/ODM/...
+
+5)
+DEV TOOLS / TOOLCHAIN
+
+Metadata, etc.
+ * PoC for opt to verify signature by multiple rebuilders
+ * buildinfo. d. n to publish buildinfo of builds it _wants_ to have
+Compilers
+ * GCC patches to upstream!
+ * Rush reproducibility patches (inc. buildpath indep debug info)
+ * Popular toolchains (C++, Java) work reproductibly and support SOURCE_PREFIX_MAP
+ * LLVM / CLANG on pair with GCC regarding reproducible "patches"
+ * Ocaml has no more reproducibility issues
+ * Intentional nondeterminism patches
+Developer utilities
+ * Git properties as "secure VCS" are analysed
+ * PDF generating docs reproducible!
+ * R data files are reproducible
+ * Strip-nondeterminism is smaller due to issues fixed "properly"
+Diffoscope
+ * Parallel diffoscope
+ * More supported file formats
+ * Integration with Taskotron
+ * FreeBSD pkg format
+ * Waterfall/ time-series gpaph at what diffoscope is doing (like Chrome Dev tools -> Network tab)
+ * Detection of order difference in many files
+Reprotest
+ * Upstream devs are using reprotest to check for reproducibility
+ * Reprotest has great usability
+ * Reprotest runs on many different platforms
+Bootstrapping
+ * Have fully mapped out bootstrapping chains for GCC, GHC, JDK, FPC, gradle, Maven
+ * I want to have raised awareness about bootstrap binaries & shared work on GNU toolchain bootstrap
+ * User accessible tools for fully bootstrap compilers
+ * Compilers will be buildable with at least one _other_ compiler.
+ * Tool to cross-bootstrap any Debian arch
+.buildinfo files
+ * Define a way to _select_ which buildinfo record should be compared
+ * Automated buildinfo creation/inspection/comparassion tool
+ * Extra optional fields in .buildinfo to help identify more causes of unreproducibility
+ * Translation tool from .buildinfo specs to Guix/Nix deriviations + vice versa
+ Specific toolchains
+ * RPM toolchain(s) analysed for sources of non-reproducibility
+ * Reproducible autotools
+ * Reproducible ELF Tool chains
+ * No more buildpath issues (SOURCE_PREFIX_MAP widely adopted)
+
+ 6)
+ USER TOOLS
+
+## Predictions
+
+* Make F-Droid.org provide simple links to reproducibility results
+* A tool to find who has been able to reproduce a package
+* Package managers allow installing reproducible packages only
+* FreeBSD pkg will policy/query for attributes like reproducibility or binary transparency
+* Users have the possibiltiy to only install reproducible packages
+* Users should be able to gather statistics about reproducibliity of packages installed on their system
+* We have a reproducible build "notary witness" server runnable by everyone
+* Tools available to give system reproducibility stats
+* F-Droid will have a binary transeparency log for all releases
+* Script to rebuild a package and compare your results against the distro's
+* Guix will allow users to select "k of n" binary providers
+* Guix will have a "health" command listing CVEs and suspicious (non-reproducible) binaries
+* Tool for any user to execute reproduce instructions
+* Tooling to create "reproducibility transparency" logs exist
+
+## Unknowns/questions
+
+* How to get fixes accepted by the Android Tools team at Google
+* Can a crowdsourced database of reproducibility test results limit its search space enough to be useful?
+* Will enough test infrastructure exist to establish reproducibility confidently?
+
+
+7)
+TESTING INFRASTRUCTURE
+
+Analyzing non-RB
+* Automatically classifying the causes of non-reproducibility
+* Advanced statistics (research on trends, tendencies, etc.)
+* Static Analysis in order to detect possible non-reproducible bugs in source code
+
+Misc improvements
+* Rebuild for each variation, to detect what effects the output
+
+Dev helping
+* Maintainers can upload packegs for repro. testing
+* Create a "fuzzing" tool to modify time|date|hostname|cwd etc. so that devs can test whether that affects them
+
+Deploy
+* Testing infra should be reproducible
+* Be able to setup tests.r-b.org locally to test patches
+* Be able to set up build for a pkg locally without whole CI infra (too)
+
+Non debian
+* ci.freebsd.org will run the testing infra for packages
+* GNU Guix will be on tests.repro-b.org
+* Measure cross-arch reproducibility of noarch RPMs
+
+debian tests
+* Test arch:all separately
+* Test arch:all cross-architecture
+* One build on one arch, per Jenkins.d.n job-run (not just in pairs build1+build2)
+
+Data storage
+* PostgreSQL is used
+* Store all the build artifacts of completed builds
+
+
+8)
+NEW DIRECTIONS
+
+Define secure VCS (Version Control System)
+Understand/analyze security properties of Git
+Run transparency log for software
+Debian FTP archive distributing build info file
+Better cross-distro build info support
+Design security-related logic, workflows and algorithms for buildinfo Files
+Having more people even at the Summit
+Crypto-signing more (reproducible) releases
+Sharing distributed databases of hashes for reproducible releases
+Having raised awareness of bootstrapping
+Start working on reproducible package installs
+Encourage projects, distros and software maintainers to publish a statement about reproducibiility of their stuff
+Store all build outputs...run diffs *later* to understand more
+Efforts on making major compilers bottstrappable has started
+Incorporate reproduible build results into binary transparency log
+Define schema for records so that two different paths to build same artifact looks good
+Write SOURC_PREFIX_MAP specification
+Push GCC guild path patches
+Push SOURCE_PREFIX_MAP into other build tools
+Achieve 97%+ reproducibility with build-path independence
+Government should require r-b by law for critical infrastructure SW
+
+_
+
diff --git a/_events/berlin2016/Gettext.md b/_events/berlin2016/Gettext.md
new file mode 100644
index 0000000..badf9e1
--- /dev/null
+++ b/_events/berlin2016/Gettext.md
@@ -0,0 +1,30 @@
+---
+layout: event_detail
+title: Gettext
+event: athens2015
+order: 150
+permalink: /events/berlin/2016/Gettext/
+---
+
+The problem is that timestamps end up in binaries because of Gettext ([[http://savannah.gnu.org/bugs/?49654][bug 49654]] discusses this issue). The timestamps originate with =xgettext=, which writes them into the header of =.pot= (the template for translations, extracted from source code strings). =msgmerge= preserves these timestamps when merging actual translations (=.po= files) with translation templates (=.pot= file). =msgfmt= preserves timestamps when it builds a binary =.mo= fil [...]
+
+If =.pot= files were generated and included by upstream developers there would be no problem, but that’s not always the case. Some argue that =.pot= files should not be part of the source tree, because they are generated artifacts. This means that they might be generated at build time, introducing build time timestamps.
+
+The POT creation date is useful for translators because it tells them whether the entire file needs to be reviewed (relative to the =.po= file). Hence, it is debatable whether it should be avoided to introduce it in the first place (by patching =xgettext=), or if it should just be excluded from the generated =.mo= files. Having the date in the binary =.mo= files is useful for recovering =.po= files from an =.mo= using =msgunfmt=, so removing it completely from =.mo= files may not be de [...]
+
+Debian implemented a patch to make xgettext respect =SOURCE_DATE_EPOCH=, but it was rejected by the former maintainer. We came up with an alternative approach: instead of using =SOURCE_DATE_EPOCH= for translation templates (which may be inaccurate) compute the latest modification time for all source files and use /that/ in the timestamp (instead of the current time). A patch has been prepared already.
+
+In addition, we are preparing patches for other approaches such as omitting the timestamp header from the =.mo= files. Upstream can then pick from one of the possible solutions.
+
+/////////////////////////////
+
+Post event email update (12/16/2016):
+
+For info:
+
+The maintainers of gettext have applied the patches we sent to remove timestamps from the
+output of gettext generated .mo files.
+
+See http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=d13f165b83701dffc14f7151419e0c00c00c0d1b
+
+-
diff --git a/_events/berlin2016/RPM.md b/_events/berlin2016/RPM.md
new file mode 100644
index 0000000..0f8b1e6
--- /dev/null
+++ b/_events/berlin2016/RPM.md
@@ -0,0 +1,65 @@
+---
+layout: event_detail
+title: RPM
+event: athens2015
+order: 80
+permalink: /events/berlin/2016/RPM/
+---
+
+brainstorming notes:
+
+Open build service ( http://openbuildservice.org/ ) that runs various configuration for RPM. Vary environment / ... easy.
+Build service sign the binaries that get published to the mirror infrastructure
+~
+Discussion point: signatures, you can copy signatures to on the newly built package to obtain the same package.
+~
+OpenSUSE might still have MD5 in some places, Fedora has switched to SHA-256.
+~
+for fedora "Mock" creates the environment and chroot, install build dependencies and build. So build is failing when missing depenency.
+(END)
+Needs to set SOURCE_DATE_EPOCH? Timestamp will be different, but timestamp is in the spec file? A end-user might want to download a source package from anywhere.
+
+Problems in RPM?
+ - What is the base level of info to have a reproducible build? Is RPM sufficient?
+
+* srpm does not specify the actual dependencies that will be used to build (gcc x.y.z). Maybe need a build-info file.
+* not custom field in rpm metadata? No, cannot add arbitrary build metadata to RPM
+ Can the metadata extended? Potentially
+* Needs a metadata of the RPM not in the RPM.
+ RPM = cpio archive, want bit-by-bit reproducible ideally
+* Issues
+ order within the archive needs to be deterministic
+ timestamp
+* Identifies the problem for reproduicibility in changing RPM
+ potential push back on removing the build time from the header
+ host name might be an issue too.
+* List of criteria -> see debian and reproducible-build.org
+ then set-up test suite to assert reproducibility
+
+* Need to record stuff?
+ - cpu_type?
+ - version of mock used?
+ - how much of the extra stuff we need to record?
+ -> You can record more than you need, it is ok to have different build info files.
+* Interesting: compare build in openSUSE and Fedora (different build system), do we get the same output?
+ Just run and use diffoscope to compare the output.
+
+* 1 or 2 small goals for the RPM
+ - Getting to know what need to change in RPM build to attain
+ - Document level of reproducibility with a standard test suite (where vary time then env then path then X...)
+
+(disgression on debian not normalizing the environment) -- 15' left
+
+* tool to reproduce the environment (build input, etc...)
+ would take build info and set-up the build environment
+* tool to generate build-info from RPM file
+ would be of use for Qubes OS
+ Idea for a hackathon tomorrow?
+ Could be part of the RPM tool itself or other place.
+ Capture uname is easy but capturing mock or similar fake environment builder.
+ take idea from the debian build infos files.
+
+Report:
+ What info on build info file to be reproducible and what kind of tool to make it easy.
+
+-
diff --git a/_events/berlin2016/RPMII.md b/_events/berlin2016/RPMII.md
new file mode 100644
index 0000000..d055125
--- /dev/null
+++ b/_events/berlin2016/RPMII.md
@@ -0,0 +1,75 @@
+---
+layout: event_detail
+title: RPMII
+event: athens2015
+order: 100
+permalink: /events/berlin/2016/RPMII/
+---
+
+Plan:
+ * create a tool to generate buildinfo files similar to Debian's
+ * later create or extend a tool to use buildinfo to create a similar environment to rebuild a package later
+
+Next steps:
+ * put the pieces together
+ * test it
+ * add it to a git repo
+
+- buildinfo spec (Debian): https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles
+ https://manpages.debian.org/cgi-bin/man.cgi?query=deb-buildinfo&apropos=0&sektion=0&manpath=Debian+unstable+sid&format=html&locale=en
+- RPM file format (draft?): http://rpm.org/devel_doc/file_format.html
+
+example buildinfo files at https://buildinfo.debian.net/
+
+to be run at the end of rpmbuild or after it, run by the tool calling rpmbuild or both (second one appending extra information)
+
+#buildinfo generator code snippet:
+echo Installed-Build-Depends:
+# might need to run outside the build chroot, because it might have an incompatible rpm version that cannot read the DB created by a newer rpm
+rpm -qa | sed -e 's/-\([^-]*-[^-]*\)\.\([^.]*\)$/:\2 (= \1)/; s/^/ /'
+# ver rel arch
+echo Environment:
+for var in LANG LC_ALL SOURCE_DATE_EPOCH ; do
+ eval value=\$$var
+ [ -n "$value" ] && echo " $var=\"$value\""
+done
+# whitelist in dpkg: https://anonscm.debian.org/git/dpkg/dpkg.git/tree/scripts/Dpkg/Build/Info.pm#n50
+
+function getos
+{
+ test -r /etc/os-release && . /etc/os-release
+ if [ -z "$ID" ] ; then
+ ID=$(cat /etc/system-release)
+ fi
+ echo "$ID"
+}
+echo "Build-Origin: $(getos)"
+echo "Build-Date: `date -R`" # - not from rpm because that will be $SOURCE_DATE_EPOCH
+
+
+
+libc6:i386 (= 2.24)
+libgcc:x86_64 (= 4.4.7-17.el6)
+
+printf 'Format: 1.0\n'
+printf 'Build-Architecture: %s\n' "$(uname -m)"
+
+Source: $(rpmspec -q --queryformat '%{name}' "$specfile")
+Binary: $(find $(rpm --eval %{_rpmdir}) -name *rpm|xargs rpm -qp --qf "%{name} ") # /usr/src/packages/RPMS/*/*.rpm or equivalent
+Version: $(rpmspec -q --queryformat '%{version}-%{release}' "$specfile")
+
+Architecture: $(rpm -q --queryformat '%{arch}' -p "$srcrpm")
+
+# other:
+Checksum-*: ... sha256sum $rpm $specfile $srcrpm # and rpm size # omit MD5+SHA1 because nobody should use that anymore
+size=$(stat -c '%s' $rpm)
+# https://anonscm.debian.org/git/dpkg/dpkg.git/tree/scripts/Dpkg/Checksums.pm
+
+Build-Path: $(rpm --eval '%{_builddir}')
+
+#
+Example looking at
+https://buildinfo.debian.net/44a20123ce26786d43af72a14aa684dade5ee927/gnome-clocks_3.22.1-1_i386.buildinfo
+https://koji.fedoraproject.org/koji/buildinfo?buildID=823737
+
+-
diff --git a/_events/berlin2016/SOURCE_PREFIX_MAP.md b/_events/berlin2016/SOURCE_PREFIX_MAP.md
new file mode 100644
index 0000000..210e499
--- /dev/null
+++ b/_events/berlin2016/SOURCE_PREFIX_MAP.md
@@ -0,0 +1,34 @@
+---
+layout: event_detail
+title: SOURCE_PREFIX_MAP
+event: athens2015
+order: 180
+permalink: /events/berlin/2016/SOURCE_PREFIX_MAP/
+---
+
+SOURCE_PREFIX_MAP
+- set by a build-tool
+- for mapping build paths
+- honoured by GCC and every build tool that generates build-paths
+- how to support multiple mappings
+
+one or multiple mappings?
+- multiple is better, allows for more intuitive overrides by child processes
+
+env variable preferred over cli
+
+separator character, space or newline?
+
+how to apply the mappings when eventually set?
+- multiple ordered mappings, child build processes append to this map (to the end)
+- child build tools apply the mapping last to first
+
+the exact format of the envvar
+- expressings multiple paths into a single string is hard
+- "common things easy, uncommon things possible"
+
+TODO:
+- (infinity0, doko) research passing newlines through shell, m4, autoconf
+- look how gdb parse and loads symbol paths to source code paths
+
+-
diff --git a/_events/berlin2016/agenda.md b/_events/berlin2016/agenda.md
new file mode 100644
index 0000000..cb6777a
--- /dev/null
+++ b/_events/berlin2016/agenda.md
@@ -0,0 +1,187 @@
+---
+layout: event_detail
+title: Agenda
+event: athens2015
+order: 10
+permalink: /events/athens2015/agenda/
+---
+
+Reproducible Builds Summit II
+December 13-15, 2016. Berlin, Germany
+
+Agenda
+
+Day 1
+Tuesday, December 13
+
+09.15 Breakfast
+
+10.00 Opening Session
+
+11.00 Project Showcase
+
+ * Reproducible FreeBSD
+ * Status stretch and buster
+ * buildinfo.debian.net
+ * openSUSE
+ * Test reproducible-builds.org. How we constantly test Debian
+ * Eliminating absolute build paths from debusgging info and other things
+ * OpenWrt, coreboot, LEDE
+ * F-Droid. Reproducible Adroid apps
+ * Building reproducible Tails ISO images [work in progress]
+
+11.50 Break
+
+12.15 Agenda Brainstorming
+https://pad.riseup.net/p/reproduciblebuildsII-agendabrainstorming
+
+13.20 Lunch Break
+
+14.30 Working Sessions I
+ * diffoscope https://pad.riseup.net/p/reproduciblebuildsII-diffoscope
+ * reprotest https://pad.riseup.net/p/reproduciblebuildsII-reprotest
+ * Documentation https://pad.riseup.net/p/reproduciblebuildsII-documentation
+ * User verification https://pad.riseup.net/p/reproduciblebuildsII-userverification
+ * Embedded https://pad.riseup.net/p/reproduciblebuildsII-embedded
+ * RPM https://pad.riseup.net/p/reproduciblebuildsII-RPM
+
+16.00 Closing Session
+
+Proposals for hacking sessions to take place later in the afternoon:
+ * SquashFS
+ * FreeBSD filesystems
+ * Pyton packages in git
+ * Gettext
+ * Make diffoscope deal with Android apks
+ * Markdowns
+
+16:20 Adjourn
+
+16:30 Hacking
+[Please feel welcome to add here links to any documentation related to your hacking efforts]
+ * http://pkgsrc.se/files.php?messageId=20161213154459.CB044FBA6@cvs.NetBSD.org
+ *
+ *
+
+Day 2
+Wednesday, December 14
+
+09.15 Breakfast
+
+10.00 Opening Session
+
+10:20 Working Sessions II
+
+ * build info files https://pad.riseup.net/p/reproduciblebuildsII-buildinfofiles
+ * RPM II https://pad.riseup.net/p/reproduciblebuildsII-RPMII https://github.com/woju/rpmbuildinfo
+ * Reproducible images https://pad.riseup.net/p/reproduciblebuildsII-reusableimages
+ * Defining reproducible builds I https://pad.riseup.net/p/reproduciblebuildsII-reproduciblebuildsdefinition
+ * End user policies https://pad.riseup.net/p/reproduciblebuildsII-enduserpolicies
+ * Test infrastructure https://pad.riseup.net/p/reproduciblebuildsII-testinfrastructure
+ * Gettext https://pad.riseup.net/p/reproduciblebuildsII-Gettext
+
+11.45 Break
+
+12.30 Skill Share
+[Note taking is not required during skill share discussions, but in case you took notes, please feel welcome to link them below]
+
+ * git-based packaging
+ * How to use C sanitizers + fuzzing
+ * How to make storage deduplicate and incentivize reproducible builds hash
+ * How to use buildinfos to analyze/test reproducibility
+ * Fedora AMA
+ * How to use emacs
+ * How to run a start-up
+ * How to apply for funding from CII
+ * How to improve cross-distro packaging https://maintainer.zq1.de
+ * How (not) to use iframes on awesome webpages *reproducible-bla.org
+ * How to sign code in git (and correctly verify the signatures)
+ * Ask me anything about building on OSX
+ * How to do automatic hardware testing
+
+13.00 Lunch Break
+
+14.20 Working Sessions III
+
+ * What Else for the Auditable Ecosystem? https://pad.riseup.net/p/reproduciblebuildsII-whatelse (was https://pad.riseup.net/p/reproduciblebuildsII-binarytransparency )
+ * SOURCE_PREFIX_MAP https://pad.riseup.net/p/reproduciblebuildsII-SOURCE_PREFIX_MAP
+ * Documentation II https://pad.riseup.net/p/reproduciblebuildsII-documentationII
+ * Defining reproducible builds II https://pad.riseup.net/p/reproduciblebuildsII-reprobuildsdefinitionII
+ * Bootstrapping https://pad.riseup.net/p/reproduciblebuildsII-bootstrapping
+ * Reproducible builds use cases https://pad.riseup.net/p/reproduciblebuildsII-usecases
+ * Reproducible builds and License/GPL compliance https://pad.riseup.net/p/rb-gpl-compliance-20161214
+
+16.00 Closing Session
+
+Proposals for hacking sessions to take place later in the afternoon:
+ * is git acceptably secure? https://pad.riseup.net/p/reproduciblebuildsII-securegit
+ * Make build images reproducible
+ * diffoscope
+ * Documentation
+ * Funding and CII
+ * RPM and hacking
+ * Nix build stuff to be incorporated with test at https://tests.reproducible-builds.org
+ * Boostrap test jenkins to replicate https://tests.reproducible-builds.org
+ * Embedded images cross-distro
+
+16:30 Adjourn
+
+16.40 Hacking
+[Please feel welcome to add here links to any documentation related to your hacking efforts]
+ *
+ *
+ *
+
+
+Day 3
+Thursday, December 15
+
+09.15 Breakfast
+
+10.00 Opening Session
+
+10:20 Working Sessions VI
+
+ * Cross-distro collaboration on reproducible builds https://pad.riseup.net/p/reproduciblebuildsII-crossdistro
+ * Boostrapping II https://pad.riseup.net/p/reproduciblebuildsII-bootstrappingII
+ * Documentation III https://pad.riseup.net/p/reproduciblebuildsII-documentationIII
+ * Binary transparency II https://pad.riseup.net/p/reproduciblebuildsII-binarytransparencyII
+ * State of Reproducible Builds https://pad.riseup.net/p/reproduciblebuildsII-stateofreproduciblebuilds
+
+11:50 Break
+
+12:05 Reporting session outcomes
+
+Proposals for hacking sessions to take place today:
+ * diffoscope debug https://pad.riseup.net/p/reproduciblebuildsII-diffoscopedebug
+ * diffoscope everything
+ * RPM
+ * Documentation
+ * buildinfo
+ * looking at buildinfo coming from different architectures
+ * Gettext
+ * FreeBSD filesystems
+ * Android documentation
+ * Reproducing the test environment and documenting it
+ * bootstrapped.org
+ * Debian infrastructure
+ * Binary transparency log
+ * Android infrastructure
+
+12:30 Hacking
+
+[Please feel welcome to add here links to any documentation related to your hacking efforts]
+ * F-droid and append-only publication log (documented through pictured sketch: reproduciblebuildsII-FDroidpublicationlog_01.jpg)
+ *
+ *
+
+13:15 Lunch Break
+
+14:30 2017 Look Ahead Session
+https://pad.riseup.net/p/reproduciblebuildsII-2017lookahead
+
+15.00 Closing Session
+
+15.30 Adjourn
+
+-
diff --git a/_events/berlin2016/agendabrainstorming.md b/_events/berlin2016/agendabrainstorming.md
new file mode 100644
index 0000000..7dbe9b1
--- /dev/null
+++ b/_events/berlin2016/agendabrainstorming.md
@@ -0,0 +1,265 @@
+---
+layout: event_detail
+title: agendabrainstorming
+event: athens2015
+order: 20
+permalink: /events/berlin/2016/agendabrainstorming/
+---
+
+AGENDA BRAINSTORMING
+
+SQUASHFS
+* fix for once SQUASHFS (1)
+* fix the mksquashfs file ordering (7)
+* have reproducible SQUASHFS
+* hack on squashfs (2)
+
+RPM
+* Removing timestamps from RPM packages (3)
+* How to make repm-build produce repr. rpms (upstream)
+* Discuss RPM metadata reproduc... issues and solutions (2)
+* How to reproduce RPM metadata?
+
+REPRODUCIBLE FILESYSTEM IMAGES (SEE ALSO: SQUASHFS)
+* What is a (cruft-free) way to save filesystems reproducibly? (defined order, etc.) (1)
+* Check/improve/update the makefs reproducibility patch in FreeBSD (1)
+* Learn how to generate filesystem images reproducibly (ISO, hybridUSB ...)
+* Figure out how to build _ext4 images_ reproducibly (in a VM for extra credit) (2)
+* How do we reproduce higher level artifacts, livecds, containers, installers, etc. (2)
+* Determine relevance of reproducibility for non-executable file formats (1)
+* Brainstorm about non-reproducible VCS->tarball steps (e.g. autoconf, etc.)
+* What do we use for base images? (2)
+
+BUILDINFO (GENERAL, DOC, ADVOCACY)
+* What is the current status of .buildinfo files? Who uses them, for what reason? (1)
+* How do we use .buildinfo? (1)
+* Disucss .buildinfo service use cases, open questions etc. (7)
+* Write a generic .buildinfo file spec (2)
+* Spread buildinfo in other projects (1)
+* If an executable buildinfo file is good for one precise/pinned version... How do we make the same thing easy to use for future versions?
+
+TOOL SUPPORT
+* Would like to work on security tools that can be used corss distro/platform. (3)
+* We need tools to find who has reproduced a build? (1)
+* What tooling is out there to help everyone determine reproducibility? (3)
+* How to solve the static library "ar" problem (without breaking apps which build from static libs).
+* How to make reproducibility issues easier to find/debug? (1)
+* How to deal with difference from compress tools like gzip.
+* Is there a way to mitigate the need to sort results of concurrent build operations?
+* Brainstorm/hack on useful docs/tools like SOURCE_DATE_EPOCH and diffoscope
+* How can we remove signatures from OSX applications (1)
+* How can we make _VM tests_ (e.g. OS system test suites) _reproducible_?
+* How should we explain package relationships OVER TIME? (1)
+
+SOURCE CODE
+- reproducible path from upstream VSC tag to downstream package
+- referencing source state from binaries (1)
+- static analysis scripts/tools to detect possible reproducibility bugs
+- how to address with the timestamp merge
+
+PROJECT STATUS
+- collect status on all projects that are trying to become reproducible (1)
+- I am using Mint; is it reproducible?
+- What about Ubuntu; is it reproducible?
+- Get pkgsrc on par with FreeBSD’s ports
+- do a regular inter-project xyz meeting (IRC? Voice?) (1)
+- make “important” packages reproducible, e.g. GCC, glibc, linux, etc (reliably + everywhere)
+- How about fixing legacy/ unmaintained software? (1)
+
+DEFINITION
+- there is a perception / accusation amongst the “opponents” of reproducible builds that “we” disagree amongst ourselves what “reproducible” means.
+- which parts of the environment have to change for a repr. build to be allowed to generate a different output? (6)
+- how/what do we hash? (2)
+- can we produce an official definition of r-b?
+
+BUILD INFO (IMPLEMENTATION) / DEBIAN INFRASTRUCTURE
+- (debian only) can we do anything productive to get =.buildinfo= files in ftp.debian.org?
+- how to patch dak (Debian Archive Kit) in 2016? (4)
+- implement/help with buildinfo distribution in Debian’s FTP (dak software)
+- hack on debrebuild
+- reach 100% r.b. for Debian pkg-pal packages
+- how do debian bulid profiles and reproducibility fit together?
+- question/Debian: building pkgs in contrib[?] reproducibly? Why do we not do it? :)
+- collect remaining infrastructure issues for reprod. Debian
+- how to make reproducible Debian chroot (get rid of non-deterministic post-installation stuff)? (2)
+- how to archive/distribute Debian buildinfos (1)
+- write dak patch to keep buildinfo files as a temporary measure.
+- discuss Debian “usrmerge” implications for reproducibility
+- scaling reproducibility testing problems and experiences
+
+DIFFOSCOPE
+- hack diffoscope to make tests less hard linked to specific tool versions (1)
+- what is the state of parallel diffoscope? (7)
+- we need parallel diffoscope
+- collect improvement ideas for tools like diffoscope, stripad[?] (2)
+- what are the main usability issues with diffoscope?
+- bring diffoscope to more platforms (1)
+- look at integrating debdiff & diffoscope
+- hacking session on diffoscope (1)
+- hands on diffoscope, check the new features (1)
+- discuss how diffoscope got better and how it could be even better
+- automatic classification of reproducibility issues in diffoscope (2)
+
+FUNDING
+* Sustained funding
+* How to keep funding sustained & fair (5)
+* Where do we get (more) funding for reproducible builds work? (1)
+
+ADVOCACY TO PROJECTS
+* Discuss/advocacy how reproducible builds can improve binary diff (1)
+* Help Mozilla prioritize R.B. HIGHER (2)
+* How to get more upstreams to care
+* How do we socialize benefits of reproducible builds? (overcome developer aversion) (1)
+
+SKILL SHARE
+* Share how Tails takes snapshots of Debian archive
+* How can I address a snapshot of e.g. the Debian archives?
+* Request for skill sharing: vagrant ???? common problems for reproducibility
+* What variables are (surprising) variables affecting builds? (3)
+* Find argument for/against different ways how pkgs built
+* Find the best way of making various packages reproducible
+* https://maintainer.zq1.de/
+
+LEGAL AND LAW
+* Using reproducible builds to improve GPL compliance (4)
+* Are there any legal implications or obstacles to reproducible builds? If so, which jurisdictions are affected? Can we somehow influence the law? In what direction? (2)
+* discuss reproducible builds benefit for GPL enforcement
+
+OUTREACH / COMMUNICATIONS (NON TECHNICAL PEOPLE)
+* What's the business case for reproducible builds? (A.K.A. How do I convince non-technical people?)
+* Explaining r-b to non-technical people (2)
+* What can we do to persuade the world that reproducibility really is important?
+* Add new stuff to SELLING POINTS web page
+* Collect benefits of reproducible builds for advocacy
+* Get reproducible builds into space! (NASA? Satellites) Mars colony?) In other words: spread it to more organizations, esp. public research or impacting
+* How do we make the every day user care? (2)
+* How to raise awareness about reproducible builds?
+
+OUTREACH / COMMUNICATIONS (DEVELOPERS)
+* Documenting non-obvious benefits of reproducible builds (7)
+* How do we explain with repro.builds are "GOOD"?
+* Are there any projects important for RB, which (we feel) are not cooperative enough? What can we do to address their issues? (1)
+* Convince tool authors about the benefits of reproducibility
+* Coordinate reproducible builds talks at every conference in 2017
+* Selling the reproducible story.
+* How do we communicate the importance of bit-for-bit reproducible?
+* Make a shared statement about bundling and binaries in the package graph. (1)
+* What are all/new uses of reproducible builds? (3)
+* Convince package authors about the benefits of reproducibility
+* How to keep in touch better after this meeting, especially news/changes/improvements (4)
+* Advocacy: How to deal with people that rejects for the sake of debuggability
+* Outrach to potential reproducers: Who can we get to run build farms?
+
+BINARY TRANSPARENCY
+* Figure out how binary artifact transparency fits into reproducible builds
+* semi OT: What's the status of binary transparency? (4)
+* What strategies exist for reproducing binaries without build metadata? (1)
+
+USER VERIFICATION
+* Design methods for end-user verification of reproducible builds (1)
+* How do we push these benefits to end users? (e.g. apt config to require reproducibility)
+* How can we _expose_ reproducibility to _end users_? (.e.g user can configure pkg manager to only install pkgs that have been built by >= N people) (1)
+* What tools can we provide for _users_ to gain trust in their systems? (3)
+* If reproducibility is used to increase trust, who actually(!) does the verification?
+* Find a good way to verify coreboot for end users (1)
+* What user-facing tools can we start building now to verify a build? (1)
+* How to let users verify builds on computers w/o keyboards (phones, embedded, etc.)
+* How can we create a "trust infrastructure" on top of reproducible builds? (4)
+* Empower users to verify builds in practice (7)
+* Where do we go next? Assure we get to 100% reproducible package collections, what else should we do? (1)
+* How do we compare reproducible build output (between developers, between projects?, etc.)
+* Discuss _user interfaces_ to repro builds: - ways to _check_ 3rd-party binaries, - ways to _choose binaries_ coming from different orgs
+
+REPROTEST
+* Discuss how reprotest could benefit outside Debian
+* Hack on reprotest (2)
+* Make reprotest great & cross-distro (1)
+* Which features should we add to build systems to help reproducibility?
+* How can we simplify finding reproducible build problems?
+
+TEST-R-B.ORG (GENERIC)
+* Rebuild everything sytsematically? Can we? Should we? Who is "we?" (1)
+* Drop iframes, how? (2)
+* Make t.r-b.org more accessible to screen readers
+* Build and diffoscope debian-cd images on Jenkins
+* Find out how to relay RB test results to the central RB Jenkins
+* *Executable* reproduce instructions? (2)
+
+TEST.R-B-ORG CROSS DISTRO
+* Hack the site for easier extendability to other tested projects (2)
+* Adding GNU Guix to t.r-b.org (1)
+* Adding openSUSE to t.r-b.org
+* Better include non-Debian in t.r-b.org (6)
+* Work on FreeBSD Jenkins instance (1)
+* Find out how to relay r test results to the central rb Jenkins (2)
+* Build and diffoscope FreeBSD release ISOs (1)
+* Start running r-b tests (arch_dep + arch_indep) on Debian GNU/kFreeBSD and more, submit buildinfos
+* Create a centralized approach/place to share reproducible build patches across distros
+
+CROSS DISTRO
+* Easy to use build environment ot make "stand-alone" apps reproducible (2)
+* Talking about reproducibility across very different domains: Android apps, GNU/Linux distctros, JavaEE, ROMs (1)
+* Hack/share issues regarding package systems and format and tools (rpm/deb/freebsd) (5)
+* Move forward the shared database of issues (vz from ath)
+* Discuss more cross-distro coordination opportunitise on an *ongoing* basis
+* Can we build common tools to record the build environment and dependencies? (2)
+* How do we better collaborate between projects? Debian, Fedora, FreeBSD, .... Issues, technology, patch tracking (3)
+* Are there any good crossplatform build containers/VM setups? (1)
+* Can we make builds verifiable below the distro package level?
+
+DOCS
+* How do we share reproduce instructions?
+* Get safe hashes everywhere (5)
+* Plan to facilitate collaborative redaction of documentation online (r-b.org)
+* Can we identify formats and toolchains, which are either critical or important for reproducible builds, which are still not taken care of? Is such a list closed?
+* Documentation for package maintainers/upstream to avoid certain pitfalls
+* What are the "best practices" for reproducible builds and we do we spread them? (2)
+* How to make RB project look even less Debian-specific (in marketing, etc.)
+* FAQ: Best practices on website
+
+SOURCE_DATE_EPOCH
+* Encourage other toolchains (clang) to adopt SOURCE_DATE_EPOCH and similar approaches (3)
+* Why do we want a SOURCE_DATE_EPOCH other than 1 Jan 1970? (2)
+* Hack Bazel to work with SOURCE_DATE_EPOCH (1)
+
+BUILD PATHS / SOURCE_PREFIX_MAP
+* Get GCC build path patches accepted
+* Turn -fdebug-prefix-map environment variable into a standard like SOURCE_DATE_EPOCH
+* Write specification for SOURCE_PREFIX_MAP and promote it (8)
+* Patch LLVM/clang to support SOURCE_PREFIX_MAP (1)
+* Discuss spec for embedded build paths
+* Look at using debugedit in strip-nondeterminism (1)
+
+COMPILERS
+* Hack on LLVM/clang/non-GNU toolchains (3)
+* Reproducing binaries with clang (5)
+* Compilers output reproducibility: What's the current state? Hack on rustc (2)
+* Figure out how to deal with pkgs that use profile-directed optimization (like GCC) (2)
+* How to reproduce Python bytecode .pyc/.pyo files? (4)
+* Is reproducibility attainable between cross builds and native ones? (4)
+
+BOOTSTRAPPING
+
+* Moving on from x86: bootstrapping new architectures without legacy hardware/software
+* Trusting trust: How close can we get to auditable bootstrapping? (3)
+* Discussing ways to bootstrap GCC from a tinyC compiler (5)
+* Can we build the whole world of Java from source? (3)
+* Drafting recommendations for compiler writers about bootstrapping (1)
+* Debating our stance towards opaque binaries used for bootstrapping (1)
+* Create vision of trustworthy system: free, reproducible, transparent, ...
+* Ensure source packages don't contain binaries/pre-built binaries (1)
+* How to reproduce packages from source only in Debian-like distros
+* How can we trust firmware? (7)
+* How can we trust hardware?
+* Reproducible binaries vs. host dependencies: what is the limit?
+* Are we okay with self-hosted languages? (2)
+
+-
+
+
+
+
+
+
+
+
diff --git a/_events/berlin2016/binarytransparency.md b/_events/berlin2016/binarytransparency.md
new file mode 100644
index 0000000..cf2c114
--- /dev/null
+++ b/_events/berlin2016/binarytransparency.md
@@ -0,0 +1,9 @@
+---
+layout: event_detail
+title: binarytransparency
+event: athens2015
+order: 170
+permalink: /events/berlin/2016/binarytransparency/
+---
+
+
diff --git a/_events/berlin2016/binarytransparencyII.md b/_events/berlin2016/binarytransparencyII.md
new file mode 100644
index 0000000..e371ade
--- /dev/null
+++ b/_events/berlin2016/binarytransparencyII.md
@@ -0,0 +1,55 @@
+---
+layout: event_detail
+title: binarytransparencyII
+event: athens2015
+order: 280
+permalink: /events/berlin/2016/binarytransparencyII/
+---
+
+Can we use the same idea as certificate transparency for the packages?
+Why do we need this:
+ * To get the common idea of what build result should be;
+ * People who do not want to build from sourced can read who had produced the same binary they are trying to install;
+How does it work for website certificates: we have the information about when the certificate was issued and when does it expire. But what do we do with the idea of revocation?
+Problems with revocation:
+ * How do I know the patch manifesto is the most recent one?
+ * Man-in-the middle can defy us the ubility to get information that the certificate was revoked (or even remember the "right" answer and use it later).
+
+What can we use for the packages:
+Hash of the log file.
+We need information about all previous changes - maybe there were revocations?
+Do we need every change of every, e.g. Debian package?
+Or can we keep the separate revocation log: not really useful.
+
+Revocation problem: there are at least 2 different situations:
+1. I found the bug in my test infrastructure, so please ignore my last result(s)
+2. I reproduced the build yesterday, but failed to reproduce it today.
+Do we need to treat them differently?
+
+Keep the logs;
+Keep buildinfo files. If we reproduced - good, if not - check the inputs. If the inputs are different, this is not so surprising (although still can be a sign of non-reproducibility)
+
+Look through all the logs:
+1. Select all buildinfo-s for the packages;
+2. Do all the output match?
+3. If output is different - are inputs different?
+
+Put buildinfos into a log. Log has tree structures. Log infrastructure should be:
+* public: no targeted attacks.
+* audible: if log is permanent, view is consistent both over time and between users.
+
+We want to look up output binaries later to run diffoscope on them.
+Keep them somewhere (cloud) stored by hash instead of names.
+
+Hash tree log:
+-> Trust buildinfo records visible
+-> We can share it share this between distros!
+We put buildinfo in there, because:
+-> Now anyone can collect it and check if info was gathered correctly.
+
+The fact that buildinfo captures output hash gives us the opportunity to look up this hash later, find the stored output binary and run diffoscope.
+
+Outcome:
+Just agree to log, then everyone can choose how to interpret them.
+
+-
diff --git a/_events/berlin2016/bootstrapping.md b/_events/berlin2016/bootstrapping.md
new file mode 100644
index 0000000..9acf10a
--- /dev/null
+++ b/_events/berlin2016/bootstrapping.md
@@ -0,0 +1,283 @@
+---
+layout: event_detail
+title: bootstrapping
+event: athens2015
+order: 210
+permalink: /events/berlin/2016/bootstrapping/
+---
+
+
+* plan (written before the session)
+** discussion
+- opaque binaries in the dependency graph ought to be minimised
+- discuss problems of trusting binary blobs for compilers
+- we need diverse language implementations and actually use them to build compilers
+** maintaining GCC 4.7
+- last version to be implemented in C only, needed to build later GCC versions that require a C++ compiler
+** maintaining GCJ
+- it’s abandoned by upstream but necessary to bootstrap OpenJDK from source
+** bootstrapping GHC
+** rustc + cargo
+** Java: maven build environment
+** ocaml?
+** building GCC without GCC
+- investigate if tinycc (or similar) could be used to build an older/simpler version of GCC
+
+* expected outcome
+- agree on the problem
+- make a public statement as to why bootstrapping is a problem and provide best practises for compiler writers
+
+* participants
+- members of Guix, NixOS, NetBSD, Qubes, and Bazel
+
+* NetBSD
+- Go: build 1.4 first then 1.6
+- many compiler packages are in the pkgsrc source tree, but it’s not clear how all of them are bootstrapped
+- the system can be built from many other systems. It first builds the toolchain (pseudo cross-compiler). It’s a bug if you cannot build NetBSD on OSX, Linux, *BSD, etc.
+
+* NixOS
+- Java is bootstrapped with a custom maintainer build of the JDK
+- Haskell: chain of three different builds to get to the latest version: https://github.com/NixOS/nixpkgs/issues/19926
+
+* Guix
+- Java is bootstrapped from GCJ -> IcedTea 6 –> IcedTea7 –> IcedTea8
+
+* Problems
+- depending on binaries for building compilers and/or build systems is bad for trust
+- the scale of the problem is getting larger as time passes: we started with just having GCC as a problem, but as time passed we got more and more new languages that are self-hosted (i.e. need an older version of themselves to be built).
+- having a long chain of builds means that build systems have to be kept alive in modern environments.
+- Go has its own linker, so to keep the bootstrap working patches have to be backported
+- later versions of GCC are written in C++
+- if you’re going to maintain an old version GCC just for a bootstrap chain you’ll have to backport new architectures. This means that our bootstrap chain is forever tied to x86 (PowerPPC users cannot bootstrap on their own).
+- generated C code is not source — it may make portability possible, but it’s not trustworthy
+- bootstrapping is not a *functional* feature, so the value isn’t immediately obvious (very much like reproducible builds)
+- the whole toolchain has bootstrapping issues (including linker and kernel…)
+
+* Ideas
+** Consensus
+- languages with multiple implementations are great, because diversity makes bootstrapping easier. For single-implementation languages we need alternative ways to get started (even if it’s inefficient)
+** Rather than depend on more binary blobs, throw more CPU time at it, e.g. by emulating an x86 CPU with qemu and then work from there.
+** Need to reach out to compiler developers: make sure that there’s a non-self-hosted path to build the first compiler — find cooperative people in compiler projects to “bootstrap” a bootstrapping project
+** try to depend only on the smallest C compiler possible
+- e.g. [[http://www.landley.net/code/tinycc/][tinycc]], [[http://pcc.ludd.ltu.se/][pcc]], [[http://www.landley.net/qcc/][qcc]]
+- coreboot folks have a simple C compiler RAMCC(?)
+** register http://bootstrappable.org, collect stories there!
+*** motivation: collect examples of backdoored compilers
+- toy example: https://manishearth.github.io/blog/2016/12/02/reflections-on-rusting-trust/
+- ken thompson: reflections on trusting trust
+- "Defending Against Compiler-Based Backdoors"
+http://blog.regehr.org/archives/1241
+- PoC||GTFO
+https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf
+
+- TODO: need more!
+*** Examples
+ - e.g. the bootstrap chain for GCC –> GCJ –> IcedTea 6 –> IcedTea7 in Guix
+ - GNU Make doesn’t need make but just a bash script
+ - Cook
+ - Guile Scheme: includes an interpreter written in C.
+ - Bazel needs Bazel to build itself, *but* you can build a minimal variant of Bazel with a shell script that runs =javac= on all Java sources, etc
+- Ant, needs itself but can be build with plain Java
+*** best practises
+- don’t throw old code away (to allow for a bootstrapping chain)
+- have an alternative implementation backend (e.g. written in C or in a language that traces back to C eventually) — simplifies porting
+*** Call for Action!
+- target it to different audiences: “if you’re a compiler writer, do this…”, “if you’re a free software dev, consider …”
+
+
+
+* Notes for the manifesto
+- Don't give "bad" examples, since we don't want to piss off upstreams. Only give "good" examples.
+
+
+== Website structure
+
+* Homepage / overview of problem
+
+(short summary from the problem - 2-3 concise sentences based on the Problems section?)
+(try to clarify what bootstrapping actually is)
+
+To have trust in our computing platforms, we should be able to follow the
+bootstrapping process - how each part was produced from source - to then feel
+confident it is built on good foundations.
+
+(more detail on the intended outcomes and benefits)
+
+(1. trust/security - most powerful/appealing motivation, mention this one first)
+
+We want to draw attention to the need for an auditable, repeatable process for
+bootstrapping programming languages, compilers, pieces of the toolchain and whole
+distributions.
+
+(2. easier porting (new platforms? languages?) - secondary benefit, important but less people are interested)
+
+Another benefit would be that it becomes easier to port these things to new hardware
+platforms.
+
+(Motivation / benefits could become a separate section of it gets too big)
+
+Compilers are often written in the language they are compiling.
+This creates a chicken-and-egg problem that leads users and
+distributors to rely on opaque, pre-built binaries of those
+compilers that they use to build newer versions of the compiler.
+We believe that those opaque binaries are a threat to user
+security and user freedom since they are not auditable; we believe
+the amount of bootstrap binaries should be minimized.
+
+* Best Practices (incl. examples, success stories?)
+
+** For compiler writers...
+
+If you're working on a compiler that is written in a language other than
+the one it's compiling, you're all set!
+
+If your compiler is written in the language that it's compiling
+(“self-hosted”), it probably falls in one of the following categories.
+
+If other implementations of this programming language exist, please make
+sure your compiler can be built with one of these. Examples include:
+
+ - The Go programming language has two implementations: [[https://golang.org/][the reference
+ implementation]] is self-hosted, and that in [[https://gcc.gnu.org][GCC]] is written in C++.
+ (TODO: check if we can build one with the other) Furthermore,
+ version 1.4 of the reference implementation was written in a
+ different language and can be used to build version 1.5.
+ - Common Lisp has several implementations. Notably [[http://www.clisp.org/][GNU clisp]] is
+ written and C and can be used to build self-hosted implementations
+ such as [[http://www.sbcl.org/][SBCL]].
+
+If your compiler targets a language for which no other implementation
+exists, then please consider maintaining a (minimal) implementation of
+the language written in a different language. Most likely this
+implementation exists, or existed at the point the programming language
+was created. Maintaining this alternate implementation has a cost;
+however, this cost should be minimal if this alternate implementation is
+used routinely to build the compiler, and if this implementation is kept
+simple—it does not need to be optimized.
+
+Examples include:
+
+ - [[https://gnu.org/software/guile][GNU Guile]], a Scheme implementation with a self-hosted compiler,
+ relies on an [[http://git.savannah.gnu.org/cgit/guile.git/tree/libguile/eval.c][Scheme interpreter written in C]] for bootstrapping
+ purposes.
+
+Please let us know if you’d like to add your compiler to this list!
+
+** For build systems writers...
+
+Build systems sometimes have chicken-and-egg problems: they may
+need a version of themselves to get built. If you are developing
+a build system, this can be avoided. We recommend that you
+provide an alternative way to build your build system.
+
+Examples include:
+
+ - [[https://gnu.org/software/make][GNU Make]] does not require a ‘make’ implementation. It can be built
+ using a [[http://git.savannah.gnu.org/cgit/make.git/tree/build.template][shell script]].
+ - [[http://ant.apache.org/][Apache Ant]] can bootstrap with a [[https://git-wip-us.apache.org/repos/asf?p=ant.git;a=blob;f=bootstrap.sh;h=60b6ece03ce78716bc036a44226f4934b541f326;hb=HEAD][shell script]]
+ that only relies on the Java compiler.
+ - [[https://bazel.build/][Bazel]] does not require Bazel to build itself but
+ can be boostrapped with a [[https://github.com/bazelbuild/bazel/blob/master/compile.sh][shell script]].
+ - [[https://buckbuild.com/][Buck]] does not require Buck to build itself. Instead, it can be
+ built using [[https://github.com/facebook/buck/blob/master/build.xml][Ant]].
+
+Build system, compared to compiler, do not need to write a full
+language compiler of its language to bootstrap. A really slow and
+unefficient build written in shell script or another older
+build system (Ant, GNU Make) can generate a minimal version of the
+build system to bootstrap a complete version of it.
+
+** For distros
+
+It is unavoidable that distributions use some binaries as part of
+their bootstrap chain. However, distributions should endeavour to
+provide traceacibility and automated reproducibility for such
+binaries. This means that:
+
+* It should be clear where the binary came from and how it was
+ produced.
+
+* Users can reproduce the binary to verify that it has not been
+ tampered with.
+
+For example, a distribution might use a binary package of GCC to build
+GCC from source. This bootstrap binary is in most cases built from a
+previous revision of the distribution's GCC package. Thus, the
+distribution can label the binary with something like "this package
+was built by running <command> on revision <hash> of the
+distribution's package repository." A user can then easily reproduce
+the binary by fetching the specified sources and running the specified
+command. This build will in most cases depend on a previous generation
+of bootstrap binaries. Thus, we get a chain of verifiable bootstrap
+binaries stretching back in time.
+
+Bootstrap binaries may also come from upstream. This would typically
+be the case when a language is first added to a distribution. In this
+case, it may not be obvious how the binary can be reproduced, but the
+distribution should at least clearly label the provenance of the
+binary, e.g. "this binary was downloaded from
+https://upstream-compiler.example.org/upstream-compiler-20161211-x86_64-linux.tar.xz".
+
+TODO: provide an example of how we do this / are going to do this in
+Nixpkgs / Guix / ...?
+
+http://git.savannah.gnu.org/cgit/guix.git/commit/?id=062134985802d85066418f6ee2f327122166a567
+
+* Collaboration projects
+
+** Continued maintenance of the GNU Compiler for Java (GCJ)
+
+Until recently the latest Java Development Kit (JDK) could be
+bootstrapped in a chain starting with GCJ (the GNU Compiler for Java)
+and the IcedTea build system. GCJ was deleted from the GNU Compiler
+Collection in October 2016, so it is now unclear how to bootstrap the
+JDK in future. To ensure that the JDK can be built from sources
+without the need for an existing installation of the OpenJDK we
+propose to continue maintaining GCJ.
+
+** Collectively maintaining GCC 4.7
+
+The C and C++ compilers of the GNU Compiler Collection make up the
+foundation of many free software distributions. Current versions of
+GCC are written in C++, which means that a C++ compiler is needed to
+build it from source. GCC 4.7 was the last version of the collection
+that could be built with a plain C compiler, a much simpler task. We
+propose to collectively maintain a subset of GCC 4.7 to ensure that we
+can build the foundation of free software distributions starting with
+a simple C compiler (such as tinyCC, pcc, etc).
+
+* Who are we? Which projects are participating
+
+* Buy-in
+
+This is nice, but what are the actual benefits of “bootstrappable”
+implementations?
+
+** For users
+
+As a user, bootstrappable implementations, together with [[https://reproducible-builds.org][reproducible
+builds]], provide confidence that you are running the code you expect to
+be running. Its source code is auditable by the developer community,
+which in turns provides reassurance that the code you’re running does
+not have backdoors.
+
+** For distributors
+
+Bootstrappable implementations provide clear provenance tracking: the
+dependency graph of your distribution packages shows how each binary was
+obtained.
+
+** For developers
+
+If you are a compiler writer, making your compiler bootstrappable from a
+different language will simplify the development process (no need to
+carry large pre-built binaries around). It will also make it easier to
+port the compiler to a different platform for which no bootstrap
+binaries exist yet.
+
+* Next Steps
+
+Try building gcc using gcc-4.7 <-- this already works (we used GCC 4.7 some months ago in Guix, but updated later for unrelated reasons)
+Try building GCC 4.7 with TinyCC
+
+-
diff --git a/_events/berlin2016/bootstrappingII.md b/_events/berlin2016/bootstrappingII.md
new file mode 100644
index 0000000..176751a
--- /dev/null
+++ b/_events/berlin2016/bootstrappingII.md
@@ -0,0 +1,35 @@
+---
+layout: event_detail
+title: bootstrappingII
+event: athens2015
+order: 260
+permalink: /events/berlin/2016/bootstrappingII/
+---
+
+From email sent to the list on 12/16/2016:
+
+
+Hello there!
+
+Here’s a WIP preview of what will soon/eventually be available at https://bootstrappable.org (once the domain has been assigned and
+mapped). It’s the website for our new “bootstrappable builds” project
+that was born during the Reproducible Builds summit 2016
+(i.e. yesterday).
+
+Thanks to all the prolific writers in the bootstrapping sessions who
+contributed so much eloquent prose! (All mistakes and omissions are
+mine.)
+
+This is currently running on a weak box in my living room, so please be
+gentle with traffic:
+
+ http://bootstrappable.elephly.net
+
+Until we get proper code hosting (already arranged for, just waiting)
+the code for the website is available here:
+
+ http://git.elephly.net/software/bootstrappable.org.git
+
+Comments and patches are very welcome!
+
+-
diff --git a/_events/berlin2016/buildinfofiles.md b/_events/berlin2016/buildinfofiles.md
new file mode 100644
index 0000000..0361690
--- /dev/null
+++ b/_events/berlin2016/buildinfofiles.md
@@ -0,0 +1,84 @@
+---
+layout: event_detail
+title: buildinfofiles
+event: athens2015
+order: 90
+permalink: /events/berlin/2016/buildinfofiles/
+---
+
+= early work
+
+a goal was to minimise the conditions needed to reproduce a binary
+
+buildinfo would be a formula to reproduce a build - it should be small as possible
+
+they don't/can't describe every possible input - build process is affected by obscure things or external, variable factors
+
+1. buildinfo files:
+record inputs to the build that produced the output - so that you can recreate its state
+
+2. analysis of buildinfo and outputs:
+as more builders provide buildinfo files, we can look for intersections (reproducible binaries), and causes of any differences (non-reproducibility)
+
+should contain the minimal information needed to produce a given binary
+
+3. the ideal (reproducible) build would depend only the source code and build dependencies
+
+buildinfo should be small, compact, and easily distributable
+
+
+= they might contain:
+
+source package (name, version, hash?)
+binaries produced (name, arch, checksums)
+build dependencies (recursively)
+build path (until recently?)
+environment variables (since recently?)
+
+in Debian, buildinfo is a separate file
+in Arch Linux, buildinfo is included in the package files (but signatures are detached)
+
+
+= consuming and aggregating buildinfo files:
+
+in Debian, buildinfo files are used when:
+ * DD uploads a package
+ * debian-ftp system distributes packages
+ * end-user installs packages
+
+and now we also realised:
+ * rebuilders
+ * buildinfo distributors
+
+
+= further work
+
+we want to collate and distribute buildinfo files from external parties too;
+not just those from Debian developers and the official builds
+
+collecting and distributing those, is a quite different task than just distributing buildinfo from Debian's official builds
+
+lamby's buildinfo.debian.net already collects and distributes some non-official buildinfo files
+
+we will need to write tools making it easy to test reproducibile and submit buildinfo,
+and tools to retrieve buildinfo files/signatures when installing
+
+signed buildinfos save people from having to build every package themselves -
+it gives them sufficient confidence to trust pre-built binaries
+
+
+= ongoing concerns
+
+buildinfo files should to be detailed enough to explain the causes of non-reproducibility
+but too much information ($HOME, hostname, installed packaged versions)
+
+argument arose that a normalised build environment evoids lots of reproducibility issues,
+like build path, environment etc. affecting the build
+whilst that would be easier, some of us think that is really a bug in the software that ought to be fixed
+
+in the extreme case,
+
+when a build-dependency affects an output binary, we may need to generate a new set of buildinfo files
+describing that situation
+
+-
diff --git a/_events/berlin2016/crossdistro.md b/_events/berlin2016/crossdistro.md
new file mode 100644
index 0000000..fbd0227
--- /dev/null
+++ b/_events/berlin2016/crossdistro.md
@@ -0,0 +1,80 @@
+---
+layout: event_detail
+title: crossdistro
+event: athens2015
+order: 250
+permalink: /events/berlin/2016/crossdistro/
+---
+
+see https://pad.riseup.net/p/rb-thu-cross-distro
+
+# Cross-distro
+
+* web infrastructure for searching, sorting
+ * don't necessarily need a single database, but maybe the distros share code to run their respective databases
+* what's in the buildinfo files
+
+## What's Debian-specific about buildinfo files?
+
+The dependencies are written as NVR - name, version, release - single string
+Doc team working on getting buildinfo specification up to the doc page
+Debian wiki says half the fields are the output of a deb-* tool
+ * But that page is outdated
+Architecture names are different, and have slightly different semantics
+ * e.g., Fedora has subarchitectures of armhbf - You could build RPMs for just that family, not optimized for any subarchitecture
+Considering adding a Known-Signature field to the buildinfo file - You're expected to copy it when you rebuild the RPM, since you don't have the private key to re-sign it
+
+Which fields are necessarily distro-specific? Which can we ask the distros to conform to a spec?
+Arch buildinfo files are included in the package, so they only include things that don't change. They're not even using RFC822 format.
+
+Signatures: buildinfo files are made at build time, but the RPM is signed later. So presumably the buildinfo file will include the hash of the unsigned package. Same package can be signed by different keys; e.g., different keys for each release of Fedora.
+Could include two checksums - One signed, one unsigned.
+
+Let's publish a buildinfo spec 1.0, and have people simply try to work to fit into it. Then come back in a year and revise for 1.1 for whatever couldn't be handled with 1.0.
+ * Or is it too early for that? Some preference to update on a rolling basis to try to get problems addressed sooner.
+ * Document what fields are expected to vary across distributions - based on the content of a Distribution field.
+
+## How can cross-distro communication happen?
+
+r-b-general seems to be OK - but needs to be more widely advertised.
+ * Docs are going to include a "Get Involved" page aimed at distro folks. This needs to be part of that.
+
+Problem that all the current r-b infrastructure is hosted on Debian. In order to get involved, you need to know Debian process: what channels to use, how to file bugs. It's a barrier to entry. Documentation could also help with this - although that still leaves a perceptual barrier to entry. Something Forge-like would be more friendly - Something that consolidates all the work in a single place. Fedora used to have FedoraHosted; now it has https://pagure.io/.
+
+Some discussion about the usability of bugs.debian.org - Submitting bugs is too hard.
+
+We discuss whether it's practical to get distros building the same thing. Doesn't seem like it. Requires too much agreement - compiler default, critical patches, etc. - that isn't worthwhile.
+
+## Generalizing buildinfo tools
+
+What about capturing buildinfo for things like distro Docker images?
+
+Is it possible to write a single tool that knows how to generate buildinfo for a wrapped build process? e.g., it would know how to capture common information like timestamp, environment variables, etc., and then has hooks for the specific output type it's generating - e.g., it knows how to capture build dependencies of a package, then how to record the build artifact at the end.
+
+Or maybe the right thing to do is to teach different tools to add to an existing buildinfo file over the course of a build process. This involves extending a lot more tools, but might require less customization per tool.
+
+Some feeling that the process will inevitably be distro-specific which necessarily limits the utility of any general-purpose tool.
+
+Maybe a shared buildinfo validator and parser? Feel unsure about parsing - People are likely to just build on existing RFC822 parsers. Some interest in a tool that understands the semantics of the format better—i.e., if you add this field, you're expected to also add this other field. (Validator would help in many of the same ways.)
+
+Can share the buildinfo database. e.g., generalize buildinfo.debian.net. This part is more complex and less distro-specific, so it seems worthwhile to share. This also ties in with binary transparency/append-only logs discussion. Needs to move to r-b.org.
+
+## Cross-distro patch tracking
+
+issues-and-notes.yaml - Stored in a Git repository that lists distro-specific issues
+https://maintainer.zq1.de - Bernhard's site that shows the version of a package in each distro, with links to source repos and patch trackers (todo: bug-trackers?)
+
+Unrelated cross-distro MLs
+https://lists.linaro.org/mailman/listinfo/cross-distro ARM-specific?
+
+## Gentoo
+
+Gentoo is interested but it's trickier for them because they support so many build options. Build options should be recorded in the buildinfo file.
+There's also a problem that GCC can get different patches that aren't reflected in the revision, so it's harder to record what you're really running.
+buildinfo can be useful for Stage 3 binaries.
+As a matter of policy, Gentoo packages can change without changing the package version
+
+Does it make sense for buildinfo files to refer to each other? e.g., this package was built with this version of GCC, here's the buildinfo file for that...
+CFLAGS need to be sorted. Probably best to do that when the buildinfo file is written. Just pick an order and use that.
+
+-
diff --git a/_events/berlin2016/diffoscope.md b/_events/berlin2016/diffoscope.md
new file mode 100644
index 0000000..039423f
--- /dev/null
+++ b/_events/berlin2016/diffoscope.md
@@ -0,0 +1,64 @@
+---
+layout: event_detail
+title: diffoscope
+event: athens2015
+order: 30
+permalink: /events/berlin/2016/diffoscope/
+---
+
+# diffoscope plan for the meeting
+
+## Reviewing the Post-Its
+
+### Improve Platform Support
+- Portability to different platforms should improve. Some tools or used abstractions (like /dev/fd) might not be available.
+- Support for distro-specific or uncommon file formats can be improved.
+- The testsuite does not work everywhere (e.g. newer versions of software can break things, currently happens for Pascal). It should be more reliable.
+
+### Integrate debdiff & diffoscope
+- Should we implement a flag in debdiff to call diffoscope?
+- Should we replace debdiff with diffoscope completely? What features of debdiff would diffoscope still need?
+- It's not really clear what the post-it author wants.
+
+### Parallel diffoscope (#842837)
+- Execution time is a serious issue, diffoscope should get faster.
+- It is not clear how well parallel Python is going to work for diffoscope due to the global interpreter lock.
+- Prior work by nomeata might exist somewhere (FIXME where?).
+- We should have a hack session on parallel diffoscope.
+
+### Marketing/Docs/Undebianization
+- https://try.diffoscope.org should be more well-known; it helpfully has a number of optional stuff for uncommon formats installed already.
+- Get the word out for non-reproducibility use cases like comparing across versions for updates or due diligence before deployment.
+- The bug tracking happens at the Debian bugtracker. That should be more visible. The website should have a "how to report bugs" section for people not familiar with the Debian bug tracker.
+
+### diffoscope Plugins
+- Should diffoscope have a plugin mechanism to support other file formats that authors may not want to upstream?
+
+### Output Format
+- Should diffoscope output markdown?
+- The output should be more accessible, e.g., for screen readers. Possibly to be implemented as a new output format.
+
+### What are Usability Issues with diffoscope?
+- Output limits could lead to spending a lot of processing time and then still not getting usable output. Should all arbitrary limits be removed?
+- Short command line options
+- Write documentation on how to implement support for a file format
+- Should diffoscope support excluding specific paths in archives to cut down runtime and ignore parts that are already known to differ?
+- Should diffoscope support disabling support for specific file formats?
+
+### Automatic Classification of Reproducibility Issues in diffoscope
+- Is this in scope for diffoscope? Should this be in a separate tool?
+- This would require knowledge of the format and lead to much more complex file format support.
+- This could be helpful in outputs, e.g. if an offset changes in an ELF binary you'd get lots of related changes that could otherwise be ignored
+
+## Action Items
+- lamby to open a bug for the output format accessibility
+- Bapt to submit his FreeBSD patches upstream
+- everyone to file tickets about portability problems
+
+## Session Proposals
+- Hacking parallel diffoscope
+- Porting diffoscope
+- diffoscope usability
+- Documenting, marketing and undebianizing diffoscope
+
+-
diff --git a/_events/berlin2016/diffoscopedebug.md b/_events/berlin2016/diffoscopedebug.md
new file mode 100644
index 0000000..c4d7913
--- /dev/null
+++ b/_events/berlin2016/diffoscopedebug.md
@@ -0,0 +1,15 @@
+---
+layout: event_detail
+title: diffoscopedebug
+event: athens2015
+order: 300
+permalink: /events/berlin/2016/diffoscopedebug/
+---
+
+Latest outcome update:
+
+The diffoscope bug was fixed, and patches for it were merged at the end of the summit. It’s all recorded on this Debian bug:
+
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848249
+
+-
diff --git a/_events/berlin2016/documentation.md b/_events/berlin2016/documentation.md
new file mode 100644
index 0000000..4abf1e5
--- /dev/null
+++ b/_events/berlin2016/documentation.md
@@ -0,0 +1,126 @@
+---
+layout: event_detail
+title: documentation
+event: athens2015
+order: 50
+permalink: /events/berlin/2016/documentation/
+---
+
+
+in between :colons: are action items, meaning somebody offered to do
+this, or if it's not a name, then we still miss somebody to do it.
+
+=====================================================================
+
+Previously
+----------
+wiki.debian.org -> everyone could edit it
+
+Current doc on reproducible-builds.org
+
+-> One issue with the website is also that there is not a lt of structure.
+-> Doc was not edited since 1 year
+-> it might be nice to edit 1 PDF generated from 20 pages currently
+
+Problem currently
+-----------------
+RB repo / website - not enough people do have access to the git repo
+How do we give access to more people / how can they contribute?
+
+What's missing? -> we do not want a webpage, we want documentation
+
+Discussion
+-----------
+
+Who is the audience of the current documentation?
+-> Package maintainers for example
+-> OpenBSD and other people who have not started making their stuff
+reproducible
+
+Documentation should not be only for Debian but cross-distro
+-> does this constitute a barrier or can it be done cross-distro?
+
+Distros or build tools?
+-> In Debian = easy to define how many percent of the repo are
+reproducible, because we have official repos. With Android apps it
+mightbe different, because there is no central build infrastructure. But
+one might just look at F-Droid, Holger answers to this. So, how many out
+of these are reproducible?
+-> As an example, one could also want to build a browser on Windows
+reproducibly and want to look into how TorBrowser did it.
+
+- Patches applied to Debian are not easily applied upstream, and are
+hard to find for other distros/projects.
+-> document stuff which is only patched in Debian and not upstream
+-> this could be done automatically (scanning through debian/patches
+meta headers)
+
+- Best practices documentation, but this needs to be ordered somehow.
+-> One could use personas or categories for restructuring the page:
+User, Upstream, Distro, Developers etc.
+
+Holger wants to get rid of the Debian wiki. and propose all information
+for Debian, Gentoo, RPMs etc. on r-b.org
+Because there is not that much Debian specific stuff to it.
+-> Several solutions have a similar mindsets, so it's a good idea to mix
+all this information on the website documentation, but using well
+structured categories (user, upstream, distro, general) and sections for
+each distro or build tool.
+
+- Some tools are shared, like GCC, but some aren't like dpkg. But the
+approaches that one takes are relevant.
+
+What's the tools behind the r-b.org website?
+-> Git repository on the bottom. markdown + jekyll. -> then one can send
+patches, pull requests or commit rights.
+-> Proposal to mirror this one Github, so that people can easily edit
+stuff and make pull requests -> but we also want mirroring :ho1ger:
+-> This should then be mentioned on the website and mailing list! :ho1ger:
+
+Who should work on this?
+- It could be cool to have an intern/Outreachy person work on the
+reorganization of the documentation, contact distros, understand how
+this works
+-> don't forget that this needs mentoring
+-> put this proposal on the agenda of Outreachy for the next round
+:actionitem:
+
+- proposal: document examples of projects that have worked on RB.
+storytelling. What's the expected reponse: See that something is
+happening? Gives a sense of the scale of RB.
+-> There should be talks and slides linked. Vagrant, Lunar, Torproject
+etc. :actionitem:
+-> Moving talks from the Debian wiki to the website :actionitem:
+-> remove the old pages from the Debian wiki so that content does not
+get duplicated :actionitem:
+
+-> don't just have a long documentation, but also a very consice FAQ for
+upstreams for example.
+-> why is reproducibility important, where do i get information for this
+or that?
+-> the ideal documentation, how would it look like? realistically!
+
+- What is the definition of "Reproducible Build"?
+-> We want to have an agreement on what it means to be reproducible. :we
+might try to define this during the summit:
+- it's better to have some definition, because we currently we don't
+have anything.
+- some proposal was "RB is the result of creating a binary from a source
+and ensure it is bit by bit identic."
+- we do have a problem about metadata and its definition
+- it's like with Free Software licenses, some are more free than others ;)
+- we could try to agree on a sentence which we all agree on at least :)
+- because "there is a lot of things we actually agree on"
+- Which tools can be used to verify reproducibility?
+ - we don't use special diff tools to see if something is the same. We
+need to have the same way of verifying and we need to include this into
+the definition or a subsection of this definition.
+ - Why? : problem with apk (android), contains jar signature, same with
+rpm which includes signatures inside the rpm. In Debian, we have the
+idea to use SHA-sums. OTOH, iOS binaries are all different, because each
+one uses a special device key
+ - that's an attack factor.
+ - Signal i.e. has a specific tool to compare two signal builds. That's
+very wrong.
+
+-
diff --git a/_events/berlin2016/documentationII.md b/_events/berlin2016/documentationII.md
new file mode 100644
index 0000000..2b4c958
--- /dev/null
+++ b/_events/berlin2016/documentationII.md
@@ -0,0 +1,164 @@
+---
+layout: event_detail
+title: documentationII
+event: athens2015
+order: 190
+permalink: /events/berlin/2016/documentationII/
+---
+
+riseup notepad for facillitating feedback:
+ https://pad.riseup.net/p/reproduciblebuildsII-FAQfeedback
+
+
+https://reproducible-builds.org/
+https://wiki.debian.org/ReproducibleBuilds - should deprecate / eventually delete this
+https://tests.reproducible-builds.org/ - surprisingly hard to find yet it has the most interesting and current info, not just for Debian but other projects' package sets
+
+Personas
+--------
+* users
+ - what does a user need to know to make a package build reproducibly?
+ - what is a reproducible build?
+ - link to definition
+* upstreams
+ - how do i make my software reproducible?
+ - how to avoid certain programming pitfalls?
+ - timestamps, etc. link to FAQ for upstream?
+* package maintainers (Debian specific?)
+
+Homepage
+--------
+ * Definition for RB (to be defined)
+
+DOCUMENTATION MOVED TO: https://pad.riseup.net/p/reproduciblebuildsII-documentationII
+
+
+Involved Projects
+-----------------
+
+Current status? no, it will get out of date quicker than anyone can update it
+ * Debian - 92% of source packages are reproducible (link to tests.r-b.o ?)
+ * FreeBSD - base is mostly ok, loader not, kernel not (but some patch/flag exists), ports (80% with external patch on the framework)
+
+ distro / project-specific pages!
+ - find a list of contacts for these projects and propose them to add information to the website or to send a link to their documentation,
+ also ask them to add a contact for RB who people can talk to
+
+ * Debian
+ https://lists.reproducible-builds.org/listinfo/rb-general, #debian-reproducible @ OFTC
+ * ArchLinux
+ * Baserock
+ * Bitcoin
+ * Coreboot
+ ask lynxis
+ * ElectroBSD
+ https://archive.fosdem.org/2016/schedule/event/electrobsd/
+ * F-Droid
+ * FreeBSD:
+ --> email alias or ML to be provided (reproducibility at FreeBSD.org)
+ * Fedora
+ * Guix
+ * LEDE
+ * NetBSD
+ * NixOS
+ * openSuSe
+ * OpenWRT
+ ask lynxis
+ * Tails: Public development list: tails-dev at boum.org
+ *
+
+Debian-related
+--------------
+ * don't forget to copy and then remove current Debian wiki pages
+
+Top level pages
+---------------
+ * adding talks page! (most from debian), videos
+ * reproducible builds definition
+
+
+Projects
+--------
+
+ * add bazel to tool page
+
+FAQ sections (instead of personified personas, let's ask concrete questions!)
+------------
+introduction to faq: to add things/links that does fit into five sections
+"what is reproducible builds?"
+"what is the status of reproducible builds?"
+"why should I (as a user) care about reproducible builds?"
+
+(single page so it is easier to search everything at once)
+* I'm interested in verifying the reproducibility of software I use
+* I'm interested in making reproducible software
+ - is it possible?
+* I'm interested in packaging/distributing software in a reproducible way
+* But it still doesnt work! -> link to Currently unresolved issues
+* What are the benefits of reproducible builds
+ - how can help with license compliance
+ - (take the work on use cases and side-benefits and put it here)
+* I don't think reproducible builds are actually useful
+ - here we need to answer all the questions like "I want to hardcode paths" etc.
+ - why can't we just normalise the <build path, environment, dependencies, whatever>?
+ - I really like <timestamps, machine/person who built the binary>!
+* how to build your how build farm?
+
+
+Get involved page
+-----------------
+* A "Get involved" page should be created
+* it should link to Currently Unresolved Issues
+* see https://wiki.debian.org/ReproducibleBuilds/Contribute for an out-of-date list of stuff we had before
+
+--- FAQ ---
+1/ how to deal with compression tools?
+ * GZIP: use gzip -n
+ * how do I make (GZIP, etc...) give reproducible output?
+ (section: projects)
+
+2/ why is reproducibility important?
+ * where do I get information for XYZ?
+ (section: users)
+
+3/ why using SOURCE_DATE_EPOCH and not simply set everything to 0 (epoch time)
+ lots of build system will reject dealing with files that have a timestamp that old (we need concrete example
+ (section: project)
+
+4/ how to write reproducible code in specific languages - e.g. Rust, Go
+
+* Python: Pyc files, PYTHONHASHSEED
+* C: uninitialized memory (msan, asan), readdir order
+* emacs bytecode
+* how/who to contact for cross distro collaboration? answer: here!
+* how to handle signatures in binaries
+* squashfs?
+
+To be discussed
+---------------
+* Merge /tools to the documentation?
+
+How to get involved?
+-----------
+* how to help various projects?
+* how to help with documentation?
+* how to help with outreach
+* how can I sponsor the effort?
+
+
+Talks
+-----
+http://www.bsdcan.org/2016/schedule/events/714.en.html
+https://archive.fosdem.org/2016/schedule/event/reproducible_freebsd_packages/
+
+https://osem.seagl.org/conference/seagl2016/program/proposal/166
+OpenWrt/LEDE: video: https://www.youtube.com/watch?v=Y1D706JCISw, slides: https://people.debian.org/~holger/2016-10-13-OpenWrt-Summit.pdf
+DebConf16: https://debconf16.debconf.org/talks/7/
+LibrePlanet: https://media.libreplanet.org/u/libreplanet/collection/beyond-reproducable-builds/
+
+
+tools
+------
+* where to find the tools
+
+-
diff --git a/_events/berlin2016/documentationIII.md b/_events/berlin2016/documentationIII.md
new file mode 100644
index 0000000..3e9d381
--- /dev/null
+++ b/_events/berlin2016/documentationIII.md
@@ -0,0 +1,36 @@
+---
+layout: event_detail
+title: documentationIII
+event: athens2015
+order: 270
+permalink: /events/berlin/2016/documentationIII/
+---
+
+Todo:
+ - mirror on github (https://github.com/reproducible-builds)
+ - Collecting talks on reproducible builds add to talk page (look at the tweet history)
+ - E.g., the recent openSuSE talk, which isn't listed yet
+ - Organize talk page and add dates (organized by project and cronologically within)
+ - Move information of the Debian wiki to the r-b.org page
+ - Add more arguments to the "buy-in" page (update page using https://pad.riseup.net/p/reproduciblebuildsII-usecases)
+ - Add a page "Start to contribute" with *clear* contacts points (MLs, IRCs, etc)
+ - Add a page for every tool (base on https://reproducible-builds.org/tools/) with more detailed things like:
+ - bug tracking instruction/link
+ - releases list
+ - link to git
+ - ...
+
+FAQ:
+ - Collecting FAQ points from lamby's specific "how to make x tool reproducible"
+ https://anonscm.debian.org/cgit/reproducible/presentations.git/tree/2015-08-20-DebConf15/2015-08-20-DebConf15.tex#n534
+ - Add link under revelant questions in the FAQ to existing parts of the reproducible-builds.org documentation page
+ - Under each "persona" add a "why should I care?" with a brief answer that relates to them and a link to the "buy-in" page of the documentation
+
+Work done (this will make great report material!):
+ https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000184.html
+ https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000185.html
+ https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000187.html
+ https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000190.html
+ https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000192.html
+
+-
diff --git a/_events/berlin2016/embedded.md b/_events/berlin2016/embedded.md
new file mode 100644
index 0000000..5645dbf
--- /dev/null
+++ b/_events/berlin2016/embedded.md
@@ -0,0 +1,35 @@
+---
+layout: event_detail
+title: embedded
+event: athens2015
+order: 70
+permalink: /events/berlin/2016/embedded/
+---
+
+Coreboot/ Embedded session
+
+Coreboot cannot (currently) ship binaries.
+
+SquashFS needs work.
+
+Proprietary Firmware is involved. So we cannot ship binaries.
+
+Cannot read a binary once it is burned in. Or if I can, how can I enssure that what I "read" is really what is installed?
+
+We want to have assurance of trust.
+
+Checking that the firmware in flash, is what I wrote into flash?
+
+If I buy from a vendor how do I know the vendor hasn't put "bad" firmware in it?
+
+Can we trust the storage?
+
+I can check the integrity of a hard disk by mounting it read-only on a trusted machine. But how can I check a flash EEprom on a trusted machine?
+
+Currently coreboot does not publish any hashes. Should they publish hashes for standard configurations?
+
+We should encourage third party vendors to publish hashes of firmware shipped with hardware.
+
+Coreboot should be encouraged to publish hashes for a select number of standard configurations/boards.
+
+-
diff --git a/_events/berlin2016/enduserpolicies.md b/_events/berlin2016/enduserpolicies.md
new file mode 100644
index 0000000..6098e89
--- /dev/null
+++ b/_events/berlin2016/enduserpolicies.md
@@ -0,0 +1,131 @@
+---
+layout: event_detail
+title: enduserpolicies
+event: athens2015
+order: 130
+permalink: /events/berlin/2016/enduserpolicies/
+---
+
+NOTES #1
+
+User Policy
+
+The aim of the discussion was to work out the user policy we could put in front of an average user.
+Though we did have diversions into what a power user would want.
+
+We realise that a power user may well want morecomplex tools - but if users need to make complex decisions as to suitible values for multiple factors they are likely to decide it is too dificult and not bother.
+
+It is assumed that the user has made the decision that they only want reproducible builds.
+We assumed the machinery needed would be in its own package which the user could install
+We refer to this as the reproducible-only package - though the name is not determined.
+Perhaps in some future version this would be installed by default.
+
+We assumed that for each distribution there would be a number of separate independent rebuilders.
+A re-builder would attempt to build new releases and determine whether they were truly reproducible.
+A re-builder would need to have daemon that noticed new releases and built them and published signed build info
+
+We assumed that by default each distrobution would publish a list of known re-builders.
+Builders will be identified by their public key.
+This list should be in the reproducible-only package.
+
+The average user can simply accept this package.
+The power user can check identities against other published sources and may add a list of other known re-builders.
+The power user may choose to be their own re-builder.
+
+Of these N known re-builder we then set a threshold K - (K is used in preference to M for as M and N can be hard to distinguish).
+K should not be set to equal N as then the loss of a single re-builder leads to a denial of service
+The default option is probably N/2.
+
+A package with a given hash is deemed to be reproducible is there are at least K re-builders from N that build it with version and inputs and generate that hash.
+If K is greater than N/2 then it is impossbile for there to be two different inatallable binaries for a single set of inputs.
+
+When a re-builder notices a new version of source,it will attempt to rebuild it with the current version of the tool chain.
+If the hash it generates matches the hash generated by the maintainer - all is good.]
+If the has differs, the re-builder checks that it is building with the same environment.
+The builder is assumed to be building with the latest - so if the distribution was built with more recent tools something has gone wrong.
+It the original build was built with older tools it will try to build it with that tool chain.
+
+If the hash now match - we have found a dependency on the tool chain.
+This could be due to a vulnerability in the old version, or just to an improvement introduced in the new one.
+The standard tools to cause an update should be triggered (build-mnu on debian)
+
+The re-builder is permitted and encouraged to publish both signed buildinfos.
+
+If the re-builder builds the same package twice with the same tool chain and the hashes do not match, it should publish both signed buildinfos
+This indicates that the build is not reproducible. The second version acts as the revocation of the first.
+The re-builder should inform the maintainer that there is a failure.
+
+
+When the user wants to install a binary package.
+For the purpose of this discussion a package is the smallest intallable unit.
+A single collection of source may produce different binary packages.
+The user wants to knwo the one they are installing is reproducilbe.
+They do not need to worry about the reproducibility of other outputs.
+For example it may be that the standard version is reproducilbe but the debug version isn't.
+Unless the user needs debug - this should not be an issue for them.
+
+It downloads the binary package and checks the hash.
+It then looks for all published signed buildinfos.
+Find those for this package and version.
+
+Set the count to zero
+For each builder
+If the builder is not in the known builder list
+ Ignore them
+ This means that an attacker cannot influence the process by publishing there own signed buildinfos as they will be ignored
+If there is a single signed buildinfo and it matches this hash
+ Increment the count
+If there are multiple signed buildinfos
+ Ignore buildinfos that do not match the one specified for the package to be installed
+ If there is only left increment the count
+ If there are still multiple buildinfos ignore it
+
+If the count is greater than the threshold the build is deemed reproducible and should be installed
+
+It is possible that the user will install a version that builds to a different version with a newer tool chain.
+This should cause the package to be updated, and the new version will be installed once it is released.
+This is equivalent to installing a package with a known CVE.
+The installer may display a warning.
+
+If the count does not reach the threshold - warn the user the build is not reproducible and do not install it
+
+Note for most users this process should be transparent.
+Although there is an extra check, it should be straightforward.
+It does not need to generate any extra log messages.
+
+We expect it to only generate log messages if there is a failure - which should be rare.
+
+Value of K
+In the discussion we assumed the default would be N/2
+However, a lax implementation may decide that a low number,e.g 2 or 3 is sufficient to demonstrate that the build is reproducible.
+The value depends how paranoid you are that the builders are not independent.
+
+Rebuilders will take time to issue their signed buildinfos.
+The higher the number, the longer the wait before sufficent signatures have been issued.
+
+//////////////////////////////////////////
+
+NOTES #2
+
+Simplest possible thing: the distribution only publishes packages that meet its own internal definition of reproducibility (e.g., it builds the same way on three different build servers)
+
+Baseline more nuanced policy: the user designates builders they're willing to trust (initially seeded from the distro), numbered N, and requires that K of those N builders achieve the same result before they're willing to install the package.
+
+Key inputs considered from the builder's buildinfo: the pair of binary package+version, and the inputs used from it
+
+Complications:
+
+* What happens if a builder can't reproduce their own result? Should probably be equivalent to revocation.
+* Do builders *have* to build with *exactly* the library versions used in the published package? For current Debian infrastructure this might require downgrading security updates.
+
+Questions:
+
+* Is there a privileged buildinfo, i.e., one that other builders are expected to match? Is this the distro's own buildinfo?
+* If builders see a situation where most users would run the package in a configuration that's different than what the archive built (e.g., because of a library security upgrade), should that be sent as a signal back upstream to trigger a rebuild of the package?
+* Can power users build the package themselves and use that to help satisfy K, or override completely?
+* How should we communicate that there are dissenting results when K agree?
+* What happens if a package stops meeting policy after it has been installed previously?
+* How many builders can we provide per architecture?
+
+-
+
diff --git a/_events/berlin2016/gpl-compliance-20161214.md b/_events/berlin2016/gpl-compliance-20161214.md
new file mode 100644
index 0000000..97b5b42
--- /dev/null
+++ b/_events/berlin2016/gpl-compliance-20161214.md
@@ -0,0 +1,69 @@
+---
+layout: event_detail
+title: gpl-compliance-20161214
+event: athens2015
+order: 230
+permalink: /events/berlin/2016/gpl-compliance-20161214/
+---
+
+
+# Using reproducible build information to help GPL compliance
+
+* spectrum of violations in the wild:
+ * didn't include license or source - beyond help
+ * middle ground: partial source: missing patches, or all dependencies, or build information
+
+- distributors know they need to, want to, but source isn't complete
+
+* compliance with GPL
+
+- GPL defines what's necessary for compliance (Makefiles, other
+ scripts for running build tools)
+
+* violators who aren't totally clueless, but don't really care either:
+
+ - incomplete source code: downloaded tarball from upstream, without
+ patches or incomplate patches
+
+ - failure to document the full process for build environment
+ (e.g. needs to be built from a specific homedir by specific user)
+
+ - shipping full toolchain as a tarball
+
+* using buildinfo files
+
+ - useful documentation for compliance issues
+
+ - distro used to build
+ - versions of toolchain
+ - locale settings
+
+* gaps
+
+ - distribution level reproducibility has been the focus
+
+ - many violations are on systems that don't even run a traditional
+ distro, just a thin layer of binaries
+
+ - move tooling from the distributions into the lower levels
+ - gcc to generate a buildinfo file
+
+* we're really not talking about distros necessarily
+* provide an SDK
+ - include common toolchain for embedded development that generates
+ proper reproducibility with .buildinfo or related information
+ necessary to build
+ - talk to linaro to ensure that their toolchains contains
+ reproducibility information
+* GCC
+ - generate buildinfo files
+ - embedding hashes of includes and other build source in binaries
+* contacting embedded distros
+ - get openembedded, angstrom, etc. using reproducibility toolchains
+
+* source code tarball tool
+ - tool that looks at a source release, and .buildinfo and identifies
+ missing pieces from the source code
+
+-
+
diff --git a/_events/berlin2016/reprobuildsdefinitionII.md b/_events/berlin2016/reprobuildsdefinitionII.md
new file mode 100644
index 0000000..2519d6d
--- /dev/null
+++ b/_events/berlin2016/reprobuildsdefinitionII.md
@@ -0,0 +1,51 @@
+---
+layout: event_detail
+title: reprobuildsdefinitionII
+event: athens2015
+order: 200
+permalink: /events/berlin/2016/reprobuildsdefinitionII/
+---
+
+# When is a build "reproducible"?
+A build is reproducible if, given the same source code, build environment and
+build instructions, any party can recreate bit-by-bit identical copies of all
+specified artifacts.
+
+The relevant attributes of the build environment, the build instructions and the
+source code, as well as the expected reproducible artifacts, are defined by the
+authors. The artifacts of a build are the parts of the build results that are the
+desired primary output.
+
+
+## Examples Section (NOT part of the definition)
+Source code is usually a version control checkout at a specific revision or
+a source code archive.
+
+Relevant attributes of the build environment would usually include dependencies
+and their versions, build configuration flags and some environment variables as
+far as they are used by the build system, such as for example, locale. It is
+preferable to reduce the set of relevant attributes of the build environment.
+
+Artifacts, for example, would include executables, distribution packages or
+filesystem images. They would usually not include a build log or similar
+secondary outputs.
+
+The reproducibility of artifacts is verified by bit-by-bit comparison. This is
+usually achieved using checksums (better: strong/cryptographically secure hash functions such as implemented in sha256sum; thanks, added. I don't want to specifically mention an algorithm, though).
+
+TODO Hyperlink me to other parts of the website!1!!
+
+#### Notes
+We've looked at the GNU discussion on the r-b@ list; we think our definition is
+a superset.
+
+Not bit-by-bit identical but similar (according to $algorithm) builds shall
+henceforth be referred to as "equivalent builds".
+
+//////////////////////////////////////////
+
+Update 20 Decmeber 2016:
+
+Definition published at https://reproducible-builds.org/docs/definition/
+
+-
diff --git a/_events/berlin2016/reproduciblebuildsdefinition.md b/_events/berlin2016/reproduciblebuildsdefinition.md
new file mode 100644
index 0000000..3ad508d
--- /dev/null
+++ b/_events/berlin2016/reproduciblebuildsdefinition.md
@@ -0,0 +1,79 @@
+---
+layout: event_detail
+title: reproduciblebuildsdefinition
+event: athens2015
+order: 120
+permalink: /events/berlin/2016/reproduciblebuildsdefinition/
+---
+
+What's the definition of a reproducible build?
+-----------------------------------------------
+
+We agree on 3 factors:
+
+* Input - same source code.
+* Output - bit by bit identical output, verifiable by a checksum. But we
+need to define the output files, because a build can also generate
+debugging files or other output.
+* Environment - what's an environment? kernel, source tree, build path,
+versions of all installed packages. discussion about trust and shipping
+vms as build environments.
+
+
+We agree on saying that
+reproducible builds is
+----------------------
+* bit-by-bit identical
+* checksum verifiable
+* specified outputs
+* no specialized comparator (make stripping part of your build - output
+must still be usable)
+
+We've set up an axis to define INPUTS (source and build environments)
+
+Axis
+----
+
+(the y-axis is "relevance", the x-axis is how hard it is to fix)
+
+* same source code
+* build instructions (command line)
+* same environment configuration, build flags
+* dependencies and their versions
+* locations where dependencies are installed
+* pre-existing keys
+
+ABOVE THIS LINE: Ideal reproducible build
+-------------------------------------------------------------------------
+BELOW THIS LINE LEFT: Minimal viable reproducible build
+ON THE RIGHT: these are things which should not be done
+
+* LOCALE
+* saved optimization metadata
+* build path prefix
+* SOURCE_EPOCH_DATE
+ * different person building
+ * host dependent optimization
+
+EASY -------------------------------------------------> HARD TO PIN/FIX
+
+ON THE RIGHT: these are things which are not reproducible and should not
+matter
+
+* other filesystem content
+ * Signing keys
+ * system time
+ * readdir order
+
+ * random data (/dev/random)
+
+
+The ideal reproducible build
+----------------------------
+* same source code
+* build instructions (command line)
+* same environment configuration, build flags
+* dependencies and their versions
+* locations where dependencies are installed
+
+-
diff --git a/_events/berlin2016/reprotest.md b/_events/berlin2016/reprotest.md
new file mode 100644
index 0000000..5f5830e
--- /dev/null
+++ b/_events/berlin2016/reprotest.md
@@ -0,0 +1,53 @@
+---
+layout: event_detail
+title: reprotest
+event: athens2015
+order: 40
+permalink: /events/berlin/2016/reprotest/
+---
+
+Platforms in the group: Debian, FreeBSD, Window River (RPM), Ubuntu/Mint
+
+reporotest was a project that Lunar proposed, and was started as a GSoC project
+in Summer 2017. It builds a package in different kinds of environment to check
+if it's reproducible.
+
+It can build a package twice with different build environment and then compare
+it with diffoscope.
+
+It's written in python, made cross-platform, without many dependencies.
+
+Some of the variations reprotests does are Linux specific for now, this needs to
+be expanded to other platforms.
+
+Variations are fixed, but an improvement would be to make them random.
+
+Need better logic to select the variations between the two builds.
+
+Ximin explains what diffoscope is, and shows us a demo.
+
+Ximin shows us the code of reprotest. It's quite straight-forward.
+
+reprotest can work using different virtual enviroments (ssh, qemu, lxc).
+
+automatic detection to build packages is only supported for Debian. More distro
+build systems need to be included.
+
+Projects outside Debian have set up their own tools to check reproducibility.
+The idea of reprotests is to have a general tool for everyone.
+
+It would be useful to make a list of all the variations that any tool could make
+to check reproducibility, and then when a package is not reproducible, bisect
+the variations to figure out which one makes the build different.
+
+Follow up: the idea is to build a package twice repeating the same environment
+as close as possible, and then start adding variations to figure out which one
+causes a difference in the build.
+
+Suggestion: Do one build in one virtual environment, and the other in a
+different virtual environment.
+
+TODO: make it work for RPM, make it work for FreeBSD (with FreeBSD specific
+variations).
+
+
diff --git a/_events/berlin2016/reusableimages.md b/_events/berlin2016/reusableimages.md
new file mode 100644
index 0000000..881e024
--- /dev/null
+++ b/_events/berlin2016/reusableimages.md
@@ -0,0 +1,56 @@
+---
+layout: event_detail
+title: reusableimages
+event: athens2015
+order: 110
+permalink: /events/berlin/2016/reusableimages/
+---
+
+agreed points:
+* docker image, vagrant box, etc. are all just "packages"
+
+* which container/VM does not matter for reproducibility
+* it does matter for ease of use/setup
+
+* perfect buildinfo is the goal
+* intermediate steps can be useful
+
+
+
+notes:
+
+* bazel, build only from directly available sources, no net, into docker
+* fdroid, vagrant to build up on VirtualBox
+* mozilla/nix, build up images per task, never use a base image
+
+* docker, AWS image, VirtualBox
+
+* basel builds up debian/ubuntu docker images
+* all source code, local and upstream, are checked into local source repo
+* 5 base images, security and legal reviewed
+
+* nix could do base images, but don't see the need yet.
+* could be used for caching to speed things up
+
+* with certain compilers (e.g. javac), wide variations can produce the
+same thing
+* can't be a buildinfo dependency, too hard to deal with problems
+
+* tools for specifying buildinfo
+* blaze forces central build infrastructure, so forces standard build envs
+* nix is a build tool first, and incidentally a package manager
+
+* Debian images can be reproducible using snapshots, specify date to
+snapshots in /etc/apt/sources.list
+
+* it is possible to not require full buildinfo in advance, if there is a
+reproducible base image that builds against user input, and it
+reproduces any given user submitted build, then that can also generate
+the buildinfo
+
+what are the benefits of bit-perfect reproducible
+* more effective caching
+* security audits, easy to track binaries to find original source
+* catching bugs by finding unexpected changes
+
+-
diff --git a/_events/berlin2016/securegit.md b/_events/berlin2016/securegit.md
new file mode 100644
index 0000000..f92bf17
--- /dev/null
+++ b/_events/berlin2016/securegit.md
@@ -0,0 +1,28 @@
+---
+layout: event_detail
+title: securegit
+event: athens2015
+order: 240
+permalink: /events/berlin/2016/securegit/
+---
+
+We discussed:
+
+- is SHA-1 safe? How easy is to to make collisions that are valid git internal structures? This is what the "potential variables" list is about.
+
+- are any of the git internal structures ambiguous about their type in a dangerous way? (We couldn't think of any.)
+
+- are there any info that git *doesn't* cover in the hash, that it should? (We couldn't find any.)
+
+- are there any times git *has* a hash, but doesn't actually *check* it? YES, and this is TERRIFYING and REALLY DANGEROUS. It's actually a problem in some repos containing linux firmware blobs and we don't know how to sound the fire alarm loud enough!!
+
+- what do git signatures cover? are they missing anything important? (We didn't find anything scary. But it might be possible to swap tags between repos in some cases, which might be weird, but we didn't (yet) describe any useful attack to do with it.)
+
+- What would it take to begin a migration, if we did want to move smoothly to a system with SHA-384 (or other stronger hash)?
+
+
+More about it on Hacker News at https://news.ycombinator.com/item?id=13195849.
+
+Overall, this whole desire for an Ecosystem Janitor Team again, which would keep an eye on all of these upstream contents and make sure their changes are publicly logged and visible so everyone is always getting the same view of upstreams, so upstream sources can be downloaded and checksummed against the public log, etc.
+
+-
diff --git a/_events/berlin2016/stateofreproduciblebuilds.md b/_events/berlin2016/stateofreproduciblebuilds.md
new file mode 100644
index 0000000..5e1a8e9
--- /dev/null
+++ b/_events/berlin2016/stateofreproduciblebuilds.md
@@ -0,0 +1,64 @@
+---
+layout: event_detail
+title: stateofreproduciblebuilds
+event: athens2015
+order: 290
+permalink: /events/berlin/2016/stateofreproduciblebuilds/
+---
+
+
+almost done
+ * R-B the idea, the goal
+ * 92% reproducible in Debian (2015: 83%, 2014: ~60%) when building in same buildpath
+ * fully reproducible bitcoin, tor, coreboot, electrobsd, webconverger
+ * communication channels setup: mailing list, IRC, webpage
+ * test.r-b.o Debian
+ * SOURCE_DATE_EPOCH specified, patches in gcc
+ * diffoscope version one (already useful)
+ * initial prototype of reprotest
+ * buildinfo for Debian
+ * Monthly IRC meetings
+ * 2 summits, community
+ * Weekly report (blog, RSS)
+ * dpkg+toolchain in Debian main
+ * 500 patches merged in Debian, +100 in openSUSE
+
+
+half-done / in progress
+ * definition of r-b
+ * 77% reproducible in Debian (with build-path issue), 23% = 2000-5000 source packages missing
+ * Talks, presentations given
+ * advocacy / use cases
+ * r-b for NetBSD, Archlinux, openSUSE, FreeBSD, Fedora, CEDE, Debian, F-droid
+ * SOURCE_PREFIX_MAP specification / GCC build path patches
+ * Diffoscope improvements
+ * buildinfo for rpm, freebsd, coreboot
+ * buildinfo distribution for DAK (Debian FTP)
+ * general buildinfo spec
+ * rpm support
+ * tests.r-b.o * (for everything non-Debian)
+ * reproducible live-media, containers, other images
+ * Documentation
+ * GNU coding guidelines / Debian Policy
+ * 800 patches unmerged (in Debian)
+ * r-b logo
+
+Not started / in planning
+ * User controls + verification
+ * Gettext (reproducible translated content)
+ * r-b for Android, OpenBSD, Ubuntu, Redhat
+ * buildinfo file distribution (putting them on mirrors/blockchain/public-signed-logs)
+ * analyze buildinfo files (detect dirty build envs, find differing binaries, find same binaries even though differing envs)
+ * tests.r-b.o / * against the 'real world' (i.e. what is distributed to users)
+ * compiler bootstrapping
+ * cross distro issue-notes
+ * pkgsrc (NetBSD & more)
+ * IoT (software running in cars, fridges etc)
+ * Windows (except ducible)
+ * MacOS + iOS
+ * Formal RFC
+ * policy & laws
+ * r-b book "r-b for Dummies", "Everything you wanted to know about r-b but were too afraid to ask"
+
+-
+
diff --git a/_events/berlin2016/testinfrastructure.md b/_events/berlin2016/testinfrastructure.md
new file mode 100644
index 0000000..2b2528b
--- /dev/null
+++ b/_events/berlin2016/testinfrastructure.md
@@ -0,0 +1,84 @@
+---
+layout: event_detail
+title: testinfrastructure
+event: athens2015
+order: 140
+permalink: /events/berlin/2016/testinfrastructure/
+---
+
+who is here?
+
+- 1 freebsd person
+- 1 openwrt/coreboot
+- many debian people
+- 1 tails person
+
+SUMMARY OF TODOS/MINUTES
+
+1. tests.reproducible-builds.org test setup
+- get ride of iframes -- talking to "u" about it
+
+2. reproducing testing set up
+- vagrant can try setting up a test set up for the builders themselves
+ - then freebsd can try to replicate the same environments
+- lynsis: document how to build openwrt2 -- change the openwrt script and coreboot script so that is doesn't depend on debian
+- tails will make a link of the results of testing tails iso so we can link from tests.r-b.org
+
+3. merge the postgres code and create new schema
+- change to postgres
+- make a script to update schema design
+
+4. data useful for other projects
+4.1 notes
+- cross distro notes?
+- way to mark a package as fixed in notes, and not display them?
+- ways to specific whether issue is debian specific
+
+4.2 making the database schema more cross distro friendly
+- CPE -- unique identifier / match names of packages across distros
+
+4.3 other people doing reproducible tests and reporting back
+- Holger wanted them to send yaml files
+- lynxis thinks kernelci.org is cool -- has an API for accepting results of kernal builds and boots
+
+
+raw minutes
+
+* the other project problems using jenkins test set up
+- cannot reproduce the test set up?
+- simplier to replicate the jenkins test environment -- too many debian dependencies?
+- bash scripts long and complicated -- maybe break out important parts so less intimidating to other potential contributors?
+
+* debian test.reproducible-builds.org
+- get rid of iframes
+- the present group less interested in talking about usability
+* scripts for creating different environments for projects (Aspirational)
+- debian
+--> hopefully build once and compare against the debian archive
+- one freebsd person / fedora
+--> system.d container
+- one openwrt/coreboot
+--> build on debian
+
+* lots and lots of talk about wanting to test jenkins
+* what can we do right now:
+- external test set up to feed to postgres
+- jernalci project? linux kernal testing? hardware set up for reporting things back? make can use similar style api?
+- other job: maybe create yaml and send tests.r-b.org to display. like tails? tails is builing iso twice and producing diffoscope result
+
+TAILS:
+- at some point tails will give link to redirect the tails test page
+
+DEBIAN:
+compare the builds to the debian builders
+* NOTES / YAML file
+- want: cross distro notes
+- currently SOME notes are debian specific
+- CPE -- match names of packages accross distros -- unique idenfier of a package.
+
+-
+
+
+
+
+
diff --git a/_events/berlin2016/usecases.md b/_events/berlin2016/usecases.md
new file mode 100644
index 0000000..4d716de
--- /dev/null
+++ b/_events/berlin2016/usecases.md
@@ -0,0 +1,70 @@
+---
+layout: event_detail
+title: usecases
+event: athens2015
+order: 220
+permalink: /events/berlin/2016/usecases/
+---
+
+old list: https://reproducible-builds.org/docs/buy-in/
+
+philosophical: doing the right thing (tm) - similar to having ingredients lists on sold food
+
+security = detect compromised build environments
+ cl: I think the Xcode Ghost example in docs/buy-in makes this sufficiently clear.
+
+security = legal enforcement backdoors
+ How is this different from malicious backdoors?
+
+increased development speed by limiting number of rebuilds of dependent packages => lower cost
+ Build systems can be significantly faster to rebuild software if the build is reproducible. It improves caching and reuse of artifacts. Tests don't need to be rerun if the binary hasn't changed.
+ Submitted: https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000192.html
+
+increased development speed by less QA work before release = because you can verify that large parts did not change
+ => better security by reduced exposure time to 0day exploits
+ Submitted: https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000187.html
+
+prove that cross-compompiling generates same result as native compiling and then speed up build on slow architectures (e.g. x86_64 is faster than arm) = in the long run spending more time on core instead of on toolchain
+ Submitted: https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000192.html
+
+
+QA and code quality = detecting issues of failing builds under rare circumstances (timing/races, number of cores, locales)
+ Submitted: https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000185.html
+bandwidth savings = faster updates with binary-delta-packages (e.g. xdelta / drpm)
+save bandwidth: torbrowser build locally and remotely and then just compare the checksum
+use less storage = save money / hardware to operate
+ Submitted: https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000187.html
+
+quality = r-b implies being able to rebuild in an automated way (which is not a given in some places), so can help business-continuity and also security when it makes it easier/possible to add security patches
+
+reliability = detecting hardware problems (bit-flips)
+debian: using buildinfo files to detect builds in unclean environments
+ = increased awareness of who builds what how
+
+easier to rebuild binaries from source = more developers/happyness
+ = not one developer being a SPOF knowing about a build, reduced responsibility of individual developers
+
+easier refactoring of build-system = identical output means all good
+ easier refactoring of any tool run during the build (scripts, compilers, code generators, etc.)
+ Submitted: https://lists.reproducible-builds.org/pipermail/rb-general/2016-December/000190.html
+
+improved/increased trust in binaries delivered by third parties
++also helps licensing information when buildinfo describes original build env and other parties are able to reproduce identical binaries from source
+
+helps trusting-trust using reverse double compilation
+
+out-of-scope (list of problems not to be solved by r-b):
+ * having understandable source code
+ * having source code without backdoors or exploitable bugs
+ * trusting hardware (some improvements with cross-compilation and emulation reproducing same binaries)
+ *
+
+
+Ensure your developers are using the real, official toolchain and libraries
+
+For mobile development, developers are often downloading the toolchains and libraries via sources that are difficult or impossible to verify.
+
+Find developers who are using unofficial or bad versions of tools and/or libraries. This also isolates the release process from all of the problems and risks associated with the developers' own machines.
+ cl: I think this is sufficiently documented in https://reproducible-builds.org/docs/buy-in/ with the 'Resisting Attacks' section on Xcode Ghost.
+
+-
diff --git a/_events/berlin2016/userverification.md b/_events/berlin2016/userverification.md
new file mode 100644
index 0000000..f71a0b4
--- /dev/null
+++ b/_events/berlin2016/userverification.md
@@ -0,0 +1,61 @@
+---
+layout: event_detail
+title: userverification
+event: athens2015
+order: 60
+permalink: /events/berlin/2016/userverification/
+---
+
+user-facing reproduciblity interactions
+=======================================
+
+raw post-it content
+-------------------
+
+- distributing build responsibility
+- reproducibility as barrier to installation
+- trusted pool of builders (what trust model?)
+- define necessary inputs for builds (visible to user's pkg manager)
+- identifiable builders
+- policy grant e.g. k-of-n in agreement
+ - fall back to build from source (?)
+- treat dissenters same as compromised keys or VCEs
+- how to determine agreement in build reports
+- workflow for failure modes
+- something ismilar to apt list-bugs
+- no UI (except for errors)
+- treat non-reproducibility as lack-of-signature
+- how do you find this info
+- "system health" (crossed out: "security number") score for operating system as a whole
+- random sampling rebuild (e.g. guix challeng)
+- using reproducibility to audit toolchain (easily)
+- reporting non-reproducibility
+- cross-platform build sepcs
+
+
+review
+------
+
+(A couple of the above, expanded with a little more context)
+
+- it's important that we incentivise repro-attempt builds *actually* being done by multiple different parties
+- we may want to use a check at package installation time for reproducibility status to encourage package creators to be reproducible!
+- we may want to use a check at package installation time for reproducibility status for safety: non-repro may indicate security issues or attacks
+- question: who is the pool of builders? how do (mechanically) define their identity? e.g. is "debian" an identity or is "buildserver123" an identity?
+- challenge: we want to determine which build reports *should* describe the same build -- we're lacking a clear (or efficient for large groups of builds) way to find that!!
+- there are many failure modes -- "not enough builds attempted" vs "too many builds conflict" -- how do we want to represent these?
+- broad agreement there should be no UI -- should mean users get repro builds by default, no interaction required, default mode is the safe mode.
+- concern that there is not a lot of easy ways to tell if the system you *have already* is actually composed of only safe things. maybe make review-and-score tools?
+- "k-of-n" means "given N build records, at least K of them must agree".
+- (not listed) there is a really tricky question in what happens *over time*: if there are 2/3rds of builders agreeing on result, then you install it, then several more reports come in which makes it only 1/3 agreement... does your existing system become unsafe? what do we do about that?
+
+
+short summary
+-------------
+
+Reproducible builds are becoming available -- now it's time to answer questions about how we want regular users (not just developers and advanced system administrators) to experience the benefits.
+Changing package managers so that they will *ONLY* install builds which are reproducibile seems like one likely avenue (both to improve end-user security, and to incentivize distro packages to demand reproducibility before releasing).
+We believe it is necessary to *SHOW* the full records of *multiple builds* to the end-user's package manager, so that the package manager can locally confirm that the builds were reproducible -- there is no improvement if we simply trust a single signature from an upstream *claiming* a package is reproducible: we want to see *multiple signitures* of independent parties who performed their own builds.
+Future work is necessary to describe how we identify different builders, how we share their logs, and how we should determine which build records are appropriate to compare.
+
+-
diff --git a/_events/berlin2016/whatelse.md b/_events/berlin2016/whatelse.md
new file mode 100644
index 0000000..117e206
--- /dev/null
+++ b/_events/berlin2016/whatelse.md
@@ -0,0 +1,78 @@
+---
+layout: event_detail
+title: whatelse
+event: athens2015
+order: 160
+permalink: /events/berlin/2016/whatelse/
+---
+
+what Else for the Auditable Ecosystem?
+--------------------------------------
+
+What other gaps from Upstream code to User-facing binary artifacts?
+
+binary transparency etc...
+
+The promise is that we have verifiable source code, we can get
+benefits of trust in the code by running stuff that was made from it.
+
+ gaps:
+
+ * repo to tarball
+ * server to user
+
+multiple builders is not the same as binary transparency.
+
+does binary-transparency-style logging perform the same functionality as trusting n of k ?
+
+"append-only" is the feature we want from publication.
+
+git fsck should be on by default.
+
+can we hire someone to do a formal security analysis of git?
+
+can we get git with a different hash?
+
+what would a "git2" look like?
+
+git commit IDs -- how do we leverage existing deployment?
+
+git issues:
+-----------
+
+ * {transfer,fetch,receive} fsckobjects on by default -- what happens
+ to existing broken git repos? can we say "only fsck after commit
+ X, which has ground truth"?
+
+ * new hash -- can we have a combined history with SHA1 before a
+ certain point and something better afterward? is there a way to
+ make this backward-compatible for pushes?
+
+ * can we have a cryptographic review of git, addressing these goal:
+
+------
+
+ 0) do we know the complete contents of the source tree at commit X?
+
+ 1) do we know the full history of the source tree at commit X?
+
+---------------------
+
+VCS -> tarball problems
+=======================
+
+Why are people using tarballs or other distribution mechanisms other
+than strong VCSen?
+
+can we push for people to offer a strong VCS as a default interface?
+
+we might need an "ecosystem janitor" team:
+
+ * identify important upstreams that don't do strong VCS
+ * import their releases into a strong VCS
+ * document what their import processes are
+
+Eric Mehyre suggests considering IPFS or other content-addressable
+store.
+
+-
--
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