▲ | indigane a day ago | |||||||
> [A]pps you install from F-Droid are signed by F-Droid rather than the developer. Having recently gone through the F-Droid release process, I learned that this is not necessarily the case anymore. F-Droid implements the reproducible builds concept. They re-build the developer's app, compare the resulting binary sans signature block, and if it matches they distribute the developer-signed binary instead of their re-built binary. This is opt-in for developers so not all apps do it this way. I'd sure like to know how common this is, I wonder if there are any statistics. | ||||||||
▲ | rixed a day ago | parent | next [-] | |||||||
If the signatures are the same, what difference does it make which binary is distributed? | ||||||||
| ||||||||
▲ | strcat a day ago | parent | prev [-] | |||||||
F-Droid only uses reproducible builds for a tiny portion of apps, and there are still significant disadvantages. It depends on the app developers always complying with F-Droid's rules otherwise users are left without updates. F-Droid only checks that the build matches, they do not review/audit the apps and will not catch hidden malicious behavior or simply non-compliance with their rules. WireGuard's app deliberately broke F-Droid's rules by including a self-updater which was not noticed by F-Droid and shipped by F-Droid. WireGuard used this to start taking over updates for itself to migrate their users away from F-Droid. F-Droid eventually found out when the WireGuard developer brought it up many months later and couldn't do anything beyond dropping the app. It had taken over updates for itself already and F-Droid wasn't in the picture anymore. The process adds a significant delay for updates but it does not actually protect users from developers in any meaningful way. This real world example with WireGuard demonstrates that. |