Maven Central is not as free as it looks
Posted on 2022-07-22 by![linsui](/web/20220928054649im_/https://f-droid.org/assets/linsui_R0MhBmhyjbRkgoeR7a1GjmV7-M0frhSmKV9c7bBjaCs=.jpg)
F-Droid is always commited to distribute FOSS Android apps. Building free software from source for Android comes with a different set of challenges from GNU/Linux distros like Debian. Android apps are cross-compiled: they are not built on the same OS as they run. On top of that, Android provides only a barebones set of libraries built-in. Like the Java ecosystem, apps are expected to fetch library binaries from Maven repos and build them into the app. To ensure that the app is only built with FOSS deps, we develop a scanning system in fdroidserver to restrict the dependency source and find problematic dependencies.
F-Droid forbids unknown Maven repos and trusts only some well-known Maven repos since 2015. From then on, some more repos are added to the list. Currently there are 8 Maven repos we trust:
- Maven Central - Google Maven Repo - JCenter - OSS Sonatype - OSS JFrog - JitPack.io - Clojars - CommonsWare - Gradle plugin repo
In 2020, JAR and AAR files embeded in the source code were forbidden and these trusted repos became the last weak point. We rely on them to provide only FOSS libs. However, none of them are guaranteed to do so and they have been a big source of non-free libs sneaking into the APKs.
The Maven Central repo is “the largest collection of Java and other open source components” and a default source of libraries for Maven and Gradle “Serving Open Source Components Since 2002”. The vast majority of libraries used in Android apps, outside of Google’s own, are fetched from Maven Central. It’s one of the most established and well-known Maven repos. Maven Central has strict requirements that the source code and the source control system information should be provided, and the license should be declared. It also requires that the group ID should match the owner’s domain and the files should be signed. Furthermore, Maven Central supports reproducible builds in a first class way which is a big help for ensuring that apps are 100% free software.
Everything sounds too good to be true. Unfortunately, it is. Though they declare that Maven Central is “OSS Repository Hosting”, they don’t require that the libs hosted on there are FOSS. Sometimes we find that a non-free lib was pulled from Maven Central and have to disable lots of affected versions of published apps.
Are those open source libs hosted on Maven Central trustable? No, not really. Some libs are tagged with a FOSS license but the source JAR files are empty. What is worse is that they even encourage uploading a dummy source JAR file of the sources to pass the requirements which makes their requirement totally meaningless. The declared license information may just be wrong and the source control system information just points to a random link or a repo with binary jars only. Another common case is that the lib itself is “open source” but it depends on other proprietary libs.
Other trusted Maven repos also have problems. The Google one hosts many proprietary libs, of course, and the open source libs may depend on those proprietary one. The OSS Sonatype and JCenter repos are synced with Maven Central, and include some extra libs. JitPack.io hosts whatever is built from GitHub, without checking the license or if there is any binary in the repo, let alone the dependencies. Clojars and Gradle plugin repo don’t have a license requirement either. The java packages from Debian and the CommonsWare repo are pretty good but barely used.
Given our limited resource and the situation, this may be an endless fighting. But we are getting more weapons. Thanks to our binary scanner, we have found lots of libs that depend on non-free deps in these Maven repos, most of which are from Maven Central. In the future we may scan the dependency map to find them before the build. However, this can’t help find libs with non-free license. Those non-free libs in our block list are mostly found by chance and experience. We are now working on more reliable methods for the future.