Add information about who built the source code and signatures and reproducibility

When using your app, the F-Droid interface doesn’t provide information about who built the app from source, who signed the app, or whether the app can be reproduced from source code. This information is only available on the website when viewed in a browser, but it’s not included in the main f-droid.apk app.

Please add important information: who compiled the app, who signed it, and how the compatibility check was performed. It’s possible that the app is open source, but the developer added unnecessary hidden functionality during compilation, then signed the app with their key and uploaded it to the f-droid directory. Without verifying that the app complies with the source code, its security cannot be guaranteed.

No, it’s not possible, F-Droid always builds, for its own repo.

FAQ - App Developers | F-Droid - Free and Open Source Android App Repository etc

look at the reproducibility status of versions

Versions 1.12.20 (616) and 1.12.14 (595) have not passed the reproducibility test, but they were published on the website and they are not signed by the f-droid developer. I don’t want to install such versions because there may be backdoors inside that were made by the app developer, and the f-droid company published possible malware. We need more information about the verification and who signed the application. The latest versions sing-box have not been tested for reproducibility at all over the last 2 months.

You’re misunderstanding how it works.

The verification server verifies later, again.

If a build of that app is not reprohucible it would not be published anyway.

Now, please try to read the docs again before making such statements.

If F-Droid always checks the reproducibility of builds, then why is there no information about new versions on the page sing-box Reproducibility Status and why are applications that did NOT pass the verification in the repository?

because the verification server did not get to that version yet

also, that is not used to publish builds, that is to check AGAIN, specially for apps that are NOT setup as reproducible

why are applications that did NOT pass the verification in the repository?

I’ve already answered that, that is never the case

eg. for version 1.3.22 you can look at the build log: sing-box | F-Droid - Free and Open Source Android App RepositoryVersion 1.13.8 (654) → Build Log

...
2026-04-15 22:33:58,947 DEBUG: Checking build/io.nekohasekai.sfa/clients/android/app/build/outputs/apk/other/release/SFA-1.13.8-unsigned.apk
2026-04-15 22:33:58,950 INFO: Successfully built io.nekohasekai.sfa:654 from d5adb54bc6c6b2c21ab6f748276c4ec62d9bb650
2026-04-15 22:33:58,975 INFO: Created directory for storing developer supplied reference binaries: 'unsigned/binaries'
2026-04-15 22:33:58,975 INFO: ...retrieving https://github.com/SagerNet/sing-box/releases/download/v1.13.8/SFA-1.13.8-universal.apk
2026-04-15 22:33:58,976 DEBUG: Starting new HTTPS connection (1): github.com:443
2026-04-15 22:33:59,251 DEBUG: https://github.com:443 "GET /SagerNet/sing-box/releases/download/v1.13.8/SFA-1.13.8-universal.apk HTTP/1.1" 302 0
2026-04-15 22:33:59,252 DEBUG: Starting new HTTPS connection (1): release-assets.githubusercontent.com:443
2026-04-15 22:33:59,343 DEBUG: https://release-assets.githubusercontent.com:443 "GET /github-production-release-asset/509091576/8af438ac-505e-4b5b-a550-cb4b4d027c06?sp=r&sv=2018-11-09&sr=b&spr=https&se=2026-04-15T23%3A13%3A42Z&rscd=attachment%3B+filename%3DSFA-1.13.8-universal.apk&rsct=application%2Fvnd.android.package-archive&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2026-04-15T22%3A13%3A15Z&ske=2026-04-15T23%3A13%3A42Z&sks=b&skv=2018-11-09&sig=1Xc7asQDruKJclAr8zeV6Arw84E3OFg8PLAnpcFlGYM%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc3NjI5NDIzOSwibmJmIjoxNzc2MjkyNDM5LCJwYXRoIjoicmVsZWFzZWFzc2V0cHJvZHVjdGlvbi5ibG9iLmNvcmUud2luZG93cy5uZXQifQ.ZVCoXfsZlhWjgPTLHiE8aJbHrTo7ZWYv0dLx-yOkvDY&response-content-disposition=attachment%3B%20filename%3DSFA-1.13.8-universal.apk&response-content-type=application%2Fvnd.android.package-archive HTTP/1.1" 200 96268999
2026-04-15 22:34:01,497 DEBUG: unsigned/binaries/io.nekohasekai.sfa_654.binary.apk: Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1

skip useless warnings

2026-04-15 22:34:02,408 DEBUG: /tmp/tmp6wdu9nh0/sigcp_io.nekohasekai.sfa_654.apk: Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v3.1 scheme (APK Signature Scheme v3.1): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1

skip useless warnings

2026-04-15 22:34:02,408 INFO: ...successfully verified
2026-04-15 22:34:02,408 INFO: compared built binary to supplied reference binary successfully
2026-04-15 22:34:02,552 DEBUG: Using APK Signature v2
2026-04-15 22:34:02,555 INFO: supplied reference binary has allowed signer 32250a4b5f3a6733df57a3b9ec16c38d2c7fc5f2f693a9636f8f7b3be3549641
2026-04-15 22:34:02,558 INFO: success: io.nekohasekai.sfa
2026-04-15 22:34:02,558 INFO: Finished
2026-04-15 22:34:02,558 INFO: 1 build succeeded

Let me rephrase/clarify/expand on what @Licaon_Kter is saying:

  1. The Verification Server (https://verification.f-droid.org/) rebuilds what is already published on f-droid org.
    • This is purely informational. For example, historically there is a large number of apps that are signed by F-Droid. The Verification Server shows which of them are reproducible and could theoretically switch to developer-signed APKs.
  2. The F-Droid build server has two options for publishing an app:
    a. Build from source and sign by F-Droid.
    b. Build from source, compare against upstream developer-signed APK, if matches publish that APK.

Observe that this means that there is no way for a developer to “hide functionality during compilation”. Everything that F-Droid publishes has been built from source.

Option b) is what the F-Droid project has historically called “Reproducible Builds”. But the main difference is in who is signing the APK in the end. Even in Option a) the app may be reproducible!

RB != developer-signed APK. RB is just a precondition for publishing a developer-signed APK on F-Droid.

Adding this info to fdroidclient

You’re not the first one asking for this. There are existing feature requests for both dimensions:

F-Droid is a community-run project, most work is done by volunteers. Stuff gets implemented when someone steps up to do it. Showing this kind of information requires changes to basically the entire stack (fdroidclient, index, fdroidserver).

Your case

In the cases that you raise above (sing-box Versions 1.12.20 (616) and 1.12.14 (595)) it is likely that the build server was able to reproduce them at the time – that’s why they were published with the developer signature – but later the Verification Server failed to. This can happen, RB can be fiddly.

Now, if you look at the diffoscopes, you will see that the diff is in the baseline.prof files. If you then read the docs, you see that this is documented as a common RB failure. For example:

Use the same CPU core number as upstream.

This is what I mean by “RB can be fiddle”. RB often just works. But when it doesn’t, it requires effort to dig in and debug it.

That’s also why RB is not a useful information to show most users. It requires technical knowledge to understand the implications, interpret the RB failure, and not just run away screaming. I have seen a large number of RB failures, and all of them were benign (false positives).

3 Likes