Are reproducible builds possible now?

1

During my research on Signal inclusion in F-Droid, I have noticed it’s not exactly clear how to ship author signatures on APKs in F-Droid. There’s this wiki page that documents the “dream of reproducible builds”:

Yet the summary (“How it is implemented as of now”) is very short, and doesn’t clearly tell authors or F-Droid repository maintainers how to actually do this, step by step (unless I am missing something obvious).

For example, there’s this “Open question: how to migrate users to new signing key?” which seems critical. For Signal, I had to backups using Oandbackup, uninstall the old app, install the new app and restore. I managed to fail the process through some SNAFU, but I guess this could be a solution… The “General Plan” below also seems a bit unclear - it’s talking about Lil’ Debian reproducibility - but it’s not clear exactly if the dream is accomplished or not.

Can we ship official binary APKs on F-Droid now with original signatures, assuming that they are free software of course? :slight_smile:

If so, what’s the best documentation on how to do so?

I guess the answer could be added to this FAQ entry as well:

Oh, and what’s with this issue:

Is that necessary to get producible builds?
Thanks!

2

Yes, they are possible now. There are two separate questions. Merely reproducing the build is pretty easy, that’s happening with 300+ APKs. See https://verification.f-droid.org and search for ‘verified’.

The second question is including an APK in f-droid.org with the developer’s signature. First, the build must be reproducible. Second, the “build metadata” file must include a Binaries: entry that points to the official APKs for fdroid verify to download, reproduce, and take the signature.

There is some more updated info on the beta of the new website:

3

So I take it that the process is:

  1. make build reproducible (out of scope? or are there docs for this in f-droid? at least publish the link to the verification page somewhere)
  2. include a Binaries field in the build metadata to point to the publicly available APK

The docs seem to be in Reproducible Builds | F-Droid - Free and Open Source Android App Repository - although they are not as clear as what is said here…

I guess i’ll tell that to people that are looking for such an answer! :slight_smile: Thanks!

4

fyi: We currently have 13 apps re-using upstream signatures. Not all
are built, not all are publishing, but we are getting there, adding
those where a plain-all-java builds looks like an easy candidate.

For the current apps, there is not something like a migration plan,
but there is an issue about pushing alerts to users and I think @hans
opened an issue about publishing fdroid signed builds along upstream
builds. Thus enabling the client to choose accordingly to what is
already installed, favoring the upstream build for new installs.

1 Like
5

what would really help us here is for someone with experience automating
KVM and/or VirtualBox instances. We have a working system, but it has
bugs and is difficult to work with.

6

I hate to say this, but I have a long time experience with Xen and VirtualBox (through Vagrant, mostly). KVM is just around the corner for me…

If you have gitlab issues or examples to throw at me, i may find time to take a look - although i’ll be away for all of may…

7

Here’s the epic story version:

Basically, we are now stuck at vagrant ssh failing to connect after a
while. The way it works is that the setup process builds a vagrant box.
Then that’s the baseline for building. For the build, the box is
started, suspended, then it makes a snapshot called “fdroidclean”. Then
vagrant up brings the snapshot up again. vagrant resume seemed to
fail sometimes. Then it ssh’s to the VM to run the build job. After
the build job is complete, it stops the VM.

This is then repeated. After a while, like 5-20 runs of this cycle, the
sshing fails. Manually typing vagrant halt or vagrant resume while
that process is running sometimes fixes it.

Here’s the code in question: