berlin-summit: add (unverified) pads from riseup, without interlinks yet

  <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&nbsp;Guix project</a></li>

---

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

_

---

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= file from a =.po= file.  The =.mo= file ends up being a part of the build artifacts.

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 desirable (although this is the approach preferred by the former gettext maintainer).

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

-

---

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.

-

---

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

-