Date: Mon, 17 Dec 2018 13:33:28 +0100
From: Natanael Copa <ncopa@alpinelinux.org>
To: Alpine Development <alpine-devel@lists.alpinelinux.org>
Subject: [alpine-devel] Report from Reproducible builds summit 2018
Message-ID: <20181217133328.4dd1ef26@ncopa-desktop.copa.dup.pw>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

I attended the reproducible builds[1] summit in paris last week, and
wanted to give a short report what I learned there and share some
thoughts on reproducible builds for Alpine.

I went to the summit because I think we should make it a long term goal
to make Alpine reproducible built, and I wanted to learn from people
with experience, what to expect and make a plan for Alpine how to get
there.

The summit in Paris was nicely organized with zero powerpoint
presentations. Instead, we were divided in to smaller groups and had a
number of group discussions and work session, where everyone was
encouraged to participate.

The notes from the session are here:
https://pad.riseup.net/p/reproduciblebuilds4-agenda

I tried to get discussions around bootstrapping rust, and how to deal
with golang packaging, but people didn't seem to be too interested in
that.

Some take away points for Alpine:

* We need a way to make older packages available, so that it is
  possible to rebuild the exact same install (or Docker image) later.
  Different distros solves this in different ways. I was told Fedora
  has some archive where they save all older packages. I was told
  Debian uses some sort of (filesystem?) snapshot archive. I have a
  couple of ideas how we could provide this.

* in order to make Alpine reproducible built, it would be good to have
  3rd party do a rebuild of all of our packages and compare with the
  offical packages. kpcyrd from Arch Linux worked on adding Alpine to
  https://tests.reproducible-builds.org and promised to follow up that.

* there are various tools that can compare different binaries to figure
  out why and what differs. I started to work on packaging diffoscope
  for alpine, but bumped into various failures in the test suite. One
  was a bug in libmagic from file(1), and this is now fixed. There were
  two other failures and with some help from diffoscope developers they
  are also fixed now.

* the work done by Suse shows that most packages will likely not need
  any patching. I got a number, ~500 packages of 10000 needed patching
  for Suse. Bernhard from Suse has also documented various common
  issues[2] (with a suggestion to a fix). He also has a tool[3] to
  monitor package versions from different distros, similar to
  release-monitoring.org. Alpine has been added.

I think we should try focus on the v3.9 release now. Once v3.9 is out I
would like to discuss how we can make alpine reproducible built. Just
mentioning some points before I forget:

* we may need to store the exact versions and/or hashes of the
  dependencies used when a package was built. I am not sure where we
  want store this. Maybe in the APKINDEX?

* we embed the signature in the .apk, which means its not possible to
  re-create the exact same .apk without having access to the private
  key. I'm not sure how to deal with that.

* I learned about this thing called IPFS[4], which may be worth have a
  closer look on.

Now, lets get v3.9 out....

-nc

[1]: https://reproducible-builds.org/events/paris2018/
[2]: https://github.com/bmwiedemann/theunreproduciblepackage
[3]: https://maintainer.zq1.de/
[4]: https://ipfs.io


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---