{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreieoaqqzln45sjc545jvob5xeuyupc7n7vhua2tjattya274hpm6re",
    "uri": "at://did:plc:34cg4tn4iwemk3v5k3n3adwf/app.bsky.feed.post/3mjowhlazo7s2"
  },
  "path": "/t/add-information-about-who-built-the-source-code-and-signatures-and-reproducibility/34271#post_7",
  "publishedAt": "2026-04-17T12:02:50.000Z",
  "site": "https://forum.f-droid.org",
  "tags": [
    "@Licaon_Kter",
    "https://verification.f-droid.org/",
    "Show a visible indicator when apps are signed by their developer and not F-Droid (#2848) · Issues · F-Droid / Client · GitLab",
    "Indicate whether version was reproducibly build or not (#1560) · Issues · F-Droid / Client · GitLab",
    "the docs"
  ],
  "textContent": "Let me rephrase/clarify/expand on what @Licaon_Kter is saying:\n\n  1. The Verification Server (https://verification.f-droid.org/) rebuilds what is already published on f-droid org.\n     * 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.\n  2. The F-Droid build server has two options for publishing an app:\na. Build from source and sign by F-Droid.\nb. Build from source, compare against upstream developer-signed APK, if matches publish that APK.\n\n\n\nObserve 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.\n\nOption 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!\n\nRB != developer-signed APK. RB is just a precondition for publishing a developer-signed APK on F-Droid.\n\n## Adding this info to fdroidclient\n\nYou’re not the first one asking for this. There are existing feature requests for both dimensions:\n\n  * Showing signer information: Show a visible indicator when apps are signed by their developer and not F-Droid (#2848) · Issues · F-Droid / Client · GitLab\n  * Showing reproducibility status: Indicate whether version was reproducibly build or not (#1560) · Issues · F-Droid / Client · GitLab\n\n\n\nF-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).\n\n## Your case\n\nIn 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.\n\nNow, 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:\n\n> Use the same CPU core number as upstream.\n\nThis 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.\n\nThat’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).",
  "title": "Add information about who built the source code and signatures and reproducibility"
}