The idea of a verification server is to automatically reproduce official releases published by f-droid.org (or any other server). This ensures that everything in the release APK came from the source code, and nothing was inserted or included during the build process. This is also useful for verifying that the build process is not including proprietary libraries.
The ultimate goal is a simple installation that any third party can make, that will continuously check for new published packages, make its own builds, and confirm that the binaries match exactly. There are many issues to resolve to get to this final destination, but the basic concept is already tested and working. (see the ‘fdroid verify’ command).
The output of multiple verification servers would then be available to the F-Droid client. The idea would be to configure the client such that it does not trust a binary until multiple verification servers are in agreement that it correct.
Verification based on APK signature
The verification process currently works by building a new unsigned APK, then copying the APK signature from the existing APK into the newly built unsigned APK. If the APK signature verifies, then the APK has been reproduced, and is marked as verified. If not, a diffoscope log is generated to show what the differences are between the two builds. The verification server needs no signing capability, just building.
Setting one up
This is still pretty raw, so expect some tinkering. It also will
likely only work on Debian, Ubuntu and other Debian-derivatives. The
first step is getting the
fdroidserver tools setup and
working. Run the fdroidserver tools directly out of git
~/code/fdroidserver/fdroid build org.adaway), that’s going to
be the easiest for now since the verification server stuff is a moving
target. The base server needs to be at minimum Debian/jessie, or there
will need to be some heavy tweaking. If you run Ubuntu or derivative
distro, you can get any packages missing from your version, like
vagrant-cachier, from this PPA:
Then you can find more on the process by reading Build Server Setup. You can also see the Continuous Integration scripts for this process to see how the whole thing can work:
Dealing with missing git repos
From time to time, app authors delete or move their git repos. With
github and other services, running
git clone on
a URL that does not exist will prompt you for a username and password
(ostensibly to check if it is an existing private repo). In order to
prevent the prompt from stalling the build jobs forever, set a fake
username and password as part of the git URL. One way to do that is to
add this to ~/.gitconfig:
[url "https://fakeusername:email@example.com"] insteadOf = https://github.com [url "https://fakeusername:firstname.lastname@example.org"] insteadOf = https://gitlab.com [url "https://fakeusername:email@example.com"] insteadOf = https://bitbucket.org