Mail archive

[alpine-devel] Report from Reproducible builds summit 2018

From: Natanael Copa <>
Date: Mon, 17 Dec 2018 13:33:28 +0100


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

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:

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

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 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 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....



Received on Mon Dec 17 2018 - 13:33:28 UTC