Confiar está bien, pero controlar es mejor

Aplicaciones reproducibles en F-Droid

Autor: Nico Alt (CC BY-NC-SA 4.0)

There’s also an English version. Es gibt auch eine deutschsprachige Version.

Cuidado: Aún no está traducido todo el texto a Español. Por eso, los últimos partes están en Inglés. Si quieres, puedes ayudarme traducir todo el texto a Español.

Gracias al software libre, los usuarios pueden verificar si una aplicación hace lo que dice. Pero solo algunas personas compilan software desde el código fuente. Por el contrario, la mayoría de las personas usa aplicaciones que obtiene de Google Play o la App Store de Apple, donde cada aplicación la compila su desarrollador, o de F-Droid, donde todas las aplicaciones las compila el propio proyecto. En los tres casos, hay que confiar en que las aplicaciones solo tienen lo que está accesible en el código público. Pero no es muy difícil modificar una aplicación antes de compilarla sin que nadie se dé cuenta. Es este el problema que resuelven las compilaciones reproducibles. Si una aplicación se compila reproduciblemente, se puede saber si alguien la modificó o si se compiló directamente desde un código fuente determinado. De esta manera, los usuarios ya no tienen que confiar plenamente en los desarrolladores o en F-Droid. Cualquiera que tenga interés puede intentar reproducir la aplicación por sí mismo.

La meta de las compilaciones reproducibles es crear un método para verificar la conexión entre el código fuente y el archivo binario, o sea, el archivo final (la aplicación) que el usuario instala en su dispositivo. Contra toda lógica, compilar una aplicación varias veces desde el mismo código fuente no resulta en los mismos archivos binarios la mayoría de las veces. En cada compilación, surgen diferencias en los binarios que no cambian el funcionamiento de la aplicación, pero que hacen imposible verificarla. Con suerte, es suficiente anotar las versiones de las herramientas de compilación (build tools). Pero hay casos que no se resuelven tan fácilmente.

Las compilaciones reproducibles no importaban tanto en el desarrollo de software, hasta que en los últimos años varios proyectos del software libre han trabajado en ellas. Cuando se puede compilar software de una manera reproducible, a uno se abren muchas posibilidades. Es por ejemplo mucho más fácil aceptar donaciones de potencia de cálculo porque no más hay que confiar totalmente en el hardware usado para compilar la software. F-Droid es un buen ejemplo: el repositorio de F-Droid solo tiene aplicaciones que son software libre. Para evitar que los desarrolladores puedan modificar las aplicaciones antes de compilarlas, F-Droid compila todas las aplicaciones por sí mismo. Eso es al mismo tiempo el mejor fuerte del proyecto como su punto más frágil: porque F-Droid realmente compila cada una aplicación ofrecida, el servidor de compilación tiene restricciones de seguridad muy altas y solo Ciaran Gultnieks que fundó el proyecto hace nueve años tiene acceso a este servidor. Este punto tan importante en la infraestructura de F-Droid también es su embotellamiento más grande y se pasa a menudo que actualizaciones se atrasan.

Ver descripción abajo

En este imagen se puede ver como un pequeño texto (hash) lo hizo imposible reproducir la aplicación OsmAnd~. El imagen muestra las resultas de diffoscope, una software para comparar archivos binarios. A la derecha, informaciones sobre las herramientas usadas fueron añadidos que son muy importantes para poder reproducir una aplicación.

Hay planes para mejorar la situación y todos basen en la idea de las compilaciones reproducibles. Una posibilidad que el autor de este texto recomendó a NewPipe, una aplicación alternativa para YouTube, se podría realizar inmediatamente. Se va así: cuando se puede reproducir una aplicación, F-Droid puede incluir el archivo binario original del desarrollador. Cuando el proceso de actualizaciones de F-Droid se atrasa otra vez, los desarrolladores de la aplicación pueden enviar una notificación a los usuarios. Con ella, los usuarios pueden actualizar a la nueva versión sin tener que esperar a F-Droid para incluir la nueva versión. Es posible porque el usuario no instaló la versión firmada de F-Droid, sino la del desarrollador. Así se puede descargar e instalar la versión del desarrollador, sin esperar a F-Droid para compilar y publicar la nueva versión. El equipo de NewPipe quiere implementar este mecanismo en los próximos meses. El otro plan de medio a largo plazo es descentralizar la infraestructura de F-Droid completamente. Cuando la mayoría de las aplicaciones compila de una manera reproducible, más contribuidores de F-Droid pueden usar más potencia de cálculo para intentar reproducir aplicaciones. Después de compilar una aplicación, ellos anotan si podían reproducir la aplicación o no. En caso de que una cantidad suficiente de servidores oficiales están de acuerdo qué una aplicación fue compilado directamente desde el código fuente, se puede incluir la aplicación en el repositorio de F-Droid. No más hay que esperar al ahora único servidor.

Con todo esto, ya pronto usuarios podrían instalar una aplicación de F-Droid que muchos ya están usando. Por restricciones del desarrollador, hasta ahora no se podía incluirla en el repositorio: Signal. Aunque hubo varias intentas, la aplicación de mensajería instantánea aún no está disponible en F-Droid. Desde cuando cambió el nombre desde su predecesor TextSecure, la organización detrás Signal no permite distribuir archivos binarios firmados de otras personas. Por esto, usuarios tienen que confiar en que nadie modificó la aplicación. Si se podría reproducir la aplicación de Signal, cualquiera incluyendo F-Droid podría chequear que la aplicación no tiene software mala. F-Droid ofrece la infraestructura para hacerlo. Ahora es el trabajo de Signal de hacer posible reproducir la aplicación.

Ver descripción abajo

La aplicación Checkey muestra detalles sobre las firmas de aplicaciones instaladas. En este imagen se ve que F-Droid firmó la aplicación Transportr (CN=FDroid), cuando los desarrolladores oficiales firmaron la aplicación Briar (O=briarproject.org).

As a user it’s not quite easy yet to see whether an app has been built reproducibly or not. The topic of reproducible builds has become popular only in recent years and because of that there doesn’t yet exist a common opinion on how to display the state of reproducibility to users. At the time of writing, only a handful of apps in F-Droid are being built reproducibly. If a warning of apps not being built reproducibly is shown to users, many users would have to dismiss it in order to keep using the store. To not “burn” the topic, at least for the beginning F-Droid has decided not to show any status indication at all. F-Droid will come back to that once reproducible builds have become more popular and UX designers have come up with “best practices”. For users still interested in finding out more, there are two possible ways to pursue. One is to use the app Checkey which shows information about signatures of installed apps. At the moment, most apps in F-Droid are signed with certificates by F-Droid itself. Apps like these show up in Checkey with the values “CN=FDroid […]” in the column “Issuer”, while apps like Briar which got included with binaries signed by their developers show up with different values, namely “O=briarproject.org”. Another way to find out more about the state of reproducibility of an app is to visit the webpage at verification.f-droid.org. All apps of F-Droid are regularly being re-built by this server which later publishes information on whether an app has been reproduced or not. Unfortunately, it doesn’t mean that being able to reproduce an app leads to immediate inclusion of binaries signed by its original developers. Instead, developers have to get active in order to publish their binaries on F-Droid.

Reproducible builds are also an important topic outside of free software. Just like developers of free software companies that create proprietary software can become targets of attacks ([1], [2], [3]). In the past it happened quite often that computer systems of companies got infected with malware that in turn injected malware into software the company produced while it was being built. To detect attacks like these and to lower the risk to get targeted at all, companies have to spend time to make their builds become reproducible. Once this is done, multiple independent build server can compile a software and compare their results at the end. If all of them produced exactly the same binary, it’s possible to ensure with a high probability that the binary doesn’t include malware. Of course, for this to be true the source code must not contain malware neither. The practice of reproducible builds therefore doesn’t replace but rather extends existing practices like pentesting and code reviews. A totally different improvement takes place in the area of delta updates. With this special form of updates users don’t download the complete file but only the difference to former versions, resulting in dramatically lowered bandwidth requirements. Delta updates have been used in Android for quite some time already and Microsoft uses them as well. Since Windows XP they are known as “express installation files”. If reproducing a program isn’t possible, tiny changes get applied to the binary with every build, resulting in unnecessarily larger updates. Among others this is one of the reason why Google is also interested in reproducible builds and therefore fixed a central bug that made reproducing apps on Android impossible.


It wasn’t much of a problem to reproduce apps on Android until version 3.0.1 of the gradle plugin. With later version reproducing apps failed on different devices because of small changes that got applied to the file resources.arsc. Briar developer Torsten Grote reported this issue to Google in June 2018 when he was trying to get the darknet messenger as the first reproducibly built app into F-Droid. He wasn’t successful since the popular public transit application Öffi found its way first into F-Droid by using an older version of the gradle plugin and thus keeping reproducibility possible. Three months later, Briar also made it into F-Droid because Grote found a workaround by using a special file system called disorderfs. Finally, in February of this year Google developers announced that the bug was fixed and that it’ll get included in next versions of the gradle plugin 3.4 and 3.5. Hopefully, more apps will find their way with those new versions reproducibly built into F-Droid.


Reproducible builds is a topic many different projects work on these days. To only name a few: the cryptocurrency Bitcoin and the Tor project worked on making their binaries build reproducibly in the past and continue to do that to this date. At Bitcoin, multiple independent developers build new versions of the software and compare the results with those of other developers. If they match, the binary gets signed by everybody. Anyone who’s interested in reproducing the programs can find instructions on the projects’ website.

Sad news came from Debian: theoretically the newest version of the Linux distribution, called Buster, has a high amount of reproducibly built software with more than 90%. However, Debian developer Holger Levsen reported in a mail to the project’s mailing list that Buster’s official binaries will only be reproducible to about 54%. The reason for this dramatic drop is that a large part of Debian packages got built before significant improvements in terms of reproducibility of the project’s build tools got implemented. They are currently thinking about doing mass rebuilds of all packages to increase this amount.


Reproducing an app is not always simple and in some cases it can require a lot of time to make it build reproducibly. But by all means, it’s worth it. Until most of the apps in F-Droid are built reproducibly and binaries signed by their developers are included in F-Droid, some more time will pass by. But the groundwork for this has been laid and the tasks that need to be done now mainly consist of fixing tinier bugs and talking with upstream developers to include their binaries in F-Droid.

Muchísimas gracias a Roboe que me ayudó bastante mejorar mi traducción.

F-Droid documentation about the verification server

Interesting for everybody who wants to reproduce apps on their own

F-Droid documentation about reproducible builds

Gives more in-depth information about the topic

Trust, Privacy, and Free Software - F-Droid.org

Related article by eighthave that also talks about reproducible builds