Draft: Add new app: Tor Browser

Required

• The app complies with the inclusion criteria
• The original app author has been notified (and does not oppose the inclusion)
• All related fdroiddata and RFP issues have been referenced in this merge request
• Builds with fdroid build and all pipelines pass

Strongly Recommended

• The upstream app source code repo contains the app metadata (summary/description/images/changelog/etc) in a Fastlane or Triple-T folder structure
• Releases are tagged

Suggested

• External repos are added as git submodules instead of srclibs
• Enable Reproducible Builds
• Multiple apks for native code

---

Most of the details are at the Tor Project link. We have the following outstanding issues:

Reproducible Builds

The fdroid built APK is almost identical to the upstream signed APK. Excluding the signature, all files in the APKs are identical. If you copy the signature with apksigcopier, the signature v1 validates successfully. But the signature v2 and v3 fail due to some differences in the zip metadata/headers. An expert for reproducible builds or APK signatures would be helpful.

I already tried zipalign, that's not the issue.

fdroid and rbm dependency management

Tor Browser has a build system (rbm) that among others ensures reproducibility. For this, it gets all kinds of build dependencies and builds them before building the actual browser with those components. Those are e.g. binutils, go, rust, node, llvm and many more. Some of them are fetched as git repositories, which F-Droid can manage through srclibs, but others are just tarballs downloaded by the build system. This means those artifacts are not scanned by fdroid scanner.

Currently, fdroid scanner reports about 4000 issues. Most of them are test files/classes and most of them are in build dependencies, not in the tor browser code itself. We could rm/scandelete those files, but the build system has other ideas. It "clones" the correct git hash of the dependencies into a build directory, foregoing all changes we would've made to those git repos, leaving us with scanignore.

If we really want reproducible builds, that all is mostly a non-issue, as Tor Project has to match F-Droid's requirements anyways.

Binaries in dependencies

From the reports of fdroid scanner the following components are most relevant:

• Tor binary as gradle dependency in tor-onion-proxy-library. tor-onion-proxy-library depends on an old version of tor-android-binary in guardian project's maven repo. The binary is replaced anyways and the whole dependency might get removed in 13.5 or 14.0.
• Glean (in application-services and firefox-android). Only published at maven.mozilla.org. Torproject seems to have its own version of glean, but the gradle dependency resolution goes to maven.mozilla.org. Fennec F-Droid and Mull (existing forks of Firefox in F-Droid) build glean themselves and replace the maven repository accordingly. If we build glean in a similar enough environment, reproducible builds could be preserved. But currently we lack a method to remove/modify the maven repo from source files (see previous section).
• concept-fetch gradle dependency in application-services. It is seemingly only published at maven.mozilla.org. Most of the notes for glean apply here as well.
• com.google.android.gms:play-services-fido:20.0.1 is included in git_clones/geckoview/mobile/android/geckoview/build.gradle. Either we replace it with a libre microG replacement or remove it altogether. Tor Project issue for it.

Probably non-issues

• The Nimbus service in git_clones/firefox-android/android-components/components/service/nimbus/build.gradle and git_clones/application-services/tools/nimbus-gradle-plugin/build.gradle. It depends on nimbus-gradle-plugin from maven.mozilla.org, but is also in a sibling directory. Tor Project already builds its own local nimbus-fml and seems to provide nimbus-gradle-plugin. And git_clones/firefox-android/android-components/components/service/nimbus/build.gradle might not be part of the built code.
• git_clones/application-services/build.gradle depends not only on glean but also on org.mozilla.rust-android-gradle:plugin:0.9.3. The projects/application-services/gradle-dependencies-list.txt file however doesn't include the rust plugin.
• The NoScript add-on was also on this list. Its zip archive is downloaded from addons.mozilla.org for Mozilla's signature. The content is readable source code, which should fulfill F-Droid's inclusion criteria.

Note that fdroid scanner doesn't see all of the dependencies, as some are tarballs downloaded during the build phase. Furthermore, the git commit checked out in git_clones/ might be different from the actual commit used by the build.

Now the big question is: Is this list complete? Are these all binaries to address? Can we scanignore (scandelete/rm do nothing for now) the other stuff from fdroid scanner? Can Tor Browser be included if we fix the above points? Answering tose questions would give us all a clear roadmap what has to be done and we can really start doing something about it. The Tor Project seemed open to change their build setup if those changes are not too complex/invasive.

---

Closes rfp#944

Previous MR: !4676 (closed)

Issue at the Tor Project: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/27539#note_2989340