Is it? Or is it a case of "It rather involved being on the other side of this airtight hatchway"[1]? The apk signature done by fdroidserver seems totally superfluous. Android is already going to verify the certificate if you try to update an app, and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password), so it's unclear what the signature validation adds, aside from maybe preventing installation failures.
[1] https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
https://www.opentech.fund/security-safety-audits/f-droid/
https://f-droid.org/2018/09/04/second-security-audit-results...
https://f-droid.org/2022/12/22/third-audit-results.html
I was involved in addressing in issues identified in the first one in 2015. It was a great experience, much more thorough than the usual "numerous static analysers and a 100 page PDF full of false positives that you often receive.
If you try to update the app. Anyone installing the app from scratch will still be vulnerable. Effectively, both cases are Trust On First Use, but AllowedAPKSigningKeys moves the First Use boundary from "the first time you install the app" to "the first time F-Droid saw the app". Izzy wrote a blog post about it a while ago.[0]
> and presumably whatever upload mechanism is already authenticated some other way (eg. api token or username/password)
IzzyOnDroid (and, I believe, F-Droid) don't have their own upload UI or authentication, they poll the upstream repo periodically.
[0]: https://f-droid.org/2023/09/03/reproducible-builds-signing-k...
Sooo how about the audits linked in >>42592444 ?
> Instead of adopting the fixes we proposed, F-Droid wrote and merged their own patch [10], ignoring repeated warnings it had significant flaws (including an incorrect implementation of v1 signature verification and making it impossible to have APKs with rotated keys in a repository).
This concerns me more than the vulnerabilities themselves. It's a pretty serious failure in leadership and shows that F-Droid is still driven by egos, not sound software engineering practices and a genuine interest in doing right for the community.
F-Droid has numerous issues:
* glacially slow to release updates even when security patches are released
* not enforcing 2FA for developer accounts
* no automatic vulnerability or malware scanning
...and more problems: https://privsec.dev/posts/android/f-droid-security-issues/
Do you mean OEM drivers or the Android Kernel, specifically?
Google invests quite a bit on hardening the (Android Commons) Kernel including compile-time/link-time & runtime mitigations (both in hardware & software).
Ex: https://android-developers.googleblog.com/2018/10/control-fl...
signify[1] is approachable at least for the power users - I could print out that man page on a T-shirt. HTTPS is ubiquitous and easy, thanks to ACME & Let's Encrypt. E2EE with optional identity verification is offered in mainstream chat apps.
And of course there are usability improvements to GPG, being made by third parties: Debian introduced package verification a couple decades ago, Github does commit verification, etc. What's to stop e.g. Nautilus or Dolphin from introducing similar features?
I wonder why there aren't more, but there are some, for example Proton's efforts towards encrypted email.
https://proton.me/support/how-to-use-pgp
(I won't mention the relative shortcomings of HTTPS and E2E chat apps here.)
Which post are you talking about? >>42592150 was made by FuturisticGoo, not me.
Also, the wording on f-droid suggests the version that f-droid hosts is built by them, rather than a version that's uploaded by the dev. If you go on any app and check the download section, it says
> It is built by F-Droid and guaranteed to correspond to this source tarball.
It also allows the user to place a little less trust on F-Droid because the developer, as well as F-Droid, must confirm any release before it can be distributed. (Now that I think of it, that probably creates an issue where if malware somehow slips in, F-Droid has no power to remove it via an automatic update. Perhaps they should have a malware response or notification system?)
More: https://f-droid.org/2023/09/03/reproducible-builds-signing-k...