Our first deterministic build: Lil’ Debi 0.4.7


We just released Lil’ Debi 0.4.7 into the Play Store and f-droid.org. It is not really different than the 0.4.6 release except in has a new, important property: the APK contents can be reproduced on other machines to the extent that the APK signature can be swapped between the official build and builds that other people have made from source, and this will still be installable. This is known as a “deterministic build” or “reproducible build”: the build process is deterministic, meaning it runs the same way each time, and that results in an APK that is reproducible by others using only the source code. There are some limitations to this, like it has to be built using similar versions of the OpenJDK 1.7 and other build tools, for example. But this process should work on any recent version of Debian or Ubuntu. Please try the process yourself, and let us know if you can verify or not:

The ultimate goal here is to make a process that reproduces the APK exactly, bit-for-bit, so that the anyone who runs the process will end up with an APK that has the exact same hash sum. As far as I can tell, the only thing that needs to be fixed in Lil’ Debi’s process is the timestamps in the ZIP format that is the APK container.

There are a number of other parallel efforts. The Tor Project has written a lot about their process for reproducible builds for the Tor Browser Bundle. Debian has made some progress in fixing the package builders to make the process deterministic.

1 comment for “Our first deterministic build: Lil’ Debi 0.4.7

  1. Hans-Christoph Steiner
    2014/09/17 at 5:07 pm

    Just made some more progress to getting the perfect deterministic build in the upcoming 0.5 release. Specifically, ant is now run with faketime to produce the same timestamps in the APK. This requires a little trick in faketime of changing the speed that time counts. While the native builds are perfectly happy to run with a completely frozen clock, `ant` will pause forever if the clock is frozen. So the solution is to run the clock really slowly, I chose 5% of normal speed. Since the execution of the build still happens at a normal rate, but time is passing at a much slower rate from the point of view of the build, it is more likely to end up with the same timestamp. It is possible to slow down the clock even more, but I think ant requires at least one second to pass by before it will continue running, so slowing down the clock even more will create a long pause in the build process. But this shouldn’t be necessary since the ZIP format timestamps only include hours and minutes, and thankfully not seconds.

Leave a Reply

Your email address will not be published. Required fields are marked *