Hello Natanel and ML,
I'm glad to read about this, thank you for this writeup!
I've looked into reproducible builds myself last year, even had a proof
of concept with a few packages. The tooling can't be re-used, as it was
based on pmbootstrap from postmarketOS, not Alpine's abuild directly.
But maybe I can help with some insights or contribute otherwise.
> * 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?
I had created a .buildinfo.json file, where I placed all dependencies
that were installed at the build time, with their versions. That file
was placed next to the main apk (so no extra buildinfo file for
subpackages) in the binary repository directory. Storing the hashes
would be even better. I chose JSON, as it's trivial to parse that with
Python, but since Alpine's build tools are lightweight and do not depend
on Python, using another format probably makes moer sense. The idea for
this file was based on Debian's buildinfo file, that is described here:
The APKINDEX is generated from the apk files, so we would need to have
the information elsewhere already, right?
> * 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.
My cheap workaround for that was: just make all files inside the .apk
file reproducible, not the apk itself. It would be better to have the
entire apk reproducible of course, but to do that, we would need to
store the signature elsewhere (e.g. create a .sig file for each .apk).
Having an extra signature file might also make it easier to allow
multiple entities to sign an apk, e.g. after an independent rebuild.
Received on Tue Dec 18 2018 - 08:27:00 UTC