When there’s a new version of the F-Droid app itself, this ought to download and install before any other updates are allowed to download. Otherwise, in a situation where a new F-Droid version is fixing a bug that makes it vulnerable to installing malicious software as updates to existing apps, that malicious software has an opening to be installed before the F-Droid app itself is updated to prevent that.
1 Like
Not really, updating the Client kills it, the rest remain un-updated…
1 Like
I agree with @strypey
If this is something that can be implemented as taking priority over other updates, when automated, can be useful.
1 Like
… until you open the newly updated version of the client, and update them. Which seems like the more sensible flow from a security POV, for reasons given.
2 Likes
that malicious software has an opening to be installed before the F-Droid app itself is updated to prevent that.
What exactly is the security concern here? Android pins the APK signer and enforces that update must be signed by the same private key.
So if you have already installed an app, any malicious update must be signed by the same key. That’s the entire security model of Android.
If the signer (may it be F-Droid or the developer) has lost their signing key to an attacker who used it to sign a malicious update, then 
is already hitting the fan.
bug that makes it vulnerable to installing malicious software as updates
I don’t think there can be such a “vulnerability” in fdroidclient. Because Android’s fundamental assumption is to pin the signing key. That is something that Android ensures, not fdroidclient.
That means that Android will still allow you to install the malicious update outside of F-Droid. Because the signing key is the same. Whatever fdroidclient does, once the signing key is lost, you can be social engineered into installing a malicious update. If the signing key is lost, Android’s fundamental security assumption is gone.
The only thing that F-Droid can do in such a situation is to pull/remove the malicious update. But this would be an index update that disables the malicious version, not an fdroidclient update. And since any such hypothetical fdroidclient update would come via an index update, the malicious app update can be removed in that very same index update!
until you open the newly updated version of the client
From a UX perspective, if you click “Update all”, it makes more sense to update fdroidclient last. Otherwise the user is confused as to why the app force-closes even though it has not yet updated everything. Sure, the users can go back, open the app switcher, scroll until they find fdroidclient, and re-open it. But it’s not an experience my grandparents would appreciate.
4 Likes
@thore Let’s assume all of this is true (I have no reason to think otherwise). All you’re telling me is that the scenario I’m describing is unlikely. All of which is good. But the change I’m proposing would make it impossible. What harm would be done my making this change, to justify leaving the unlikely but still present risk of vulnerability in place?
1 Like
@strypey You have yet to answer the above question: what category of vulnerability is this solving by updating 1st than last?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
When there are new versions of F-Droid itself, I think it would be a wise precaution to push them separately. So that the app is updated and restarted before downloading and handling updates from other apps.
This might address the valid UX issue raised about the suggestion I made here;
I was going to post it there, but the topic is now locked. Please feel free to reopen that topic and merge this one into it.
You mean aside from the potential exploit I described in the OP?
Reducing avoidable attack surface is a well-established security principle. The onus isn’t on me to prove a practical attack currently exists. If the F-Droid team want to wait for one to be discovered and exploited instead of taking the precaution of removing this attack surface, eg by updating the F-Droid client separately before pushing updates to any other apps, that’s up to them. The risk has been pointed out, and a simple mitigation suggested. That’s all I can do.
1 Like
Thanks admins for merging the new topic. Can I also suggest changing the topic title to ‘EDIT: Pushing new versions of F-Droid itself separately from other updates’, to reflect the new suggestion? Feel free to delete this comment when you do (or decide not to, as appropriate).
The same “argument” holds the other way, too: all updates for anything potentially close (or open 
) vulns, so they should be prioritized before stopping the workflow via killing the app to update it. That’s actually what I prefer.
Obviously, not only F-Droid can have attack surface, so, to be utterly certain of being protected from any/every/all nebulous theoretical whatevers, it’s absolutely best practice to smash the device thoroughly upon obtaining. /s 
Sure, but none of those apps are the app store that’s handling the update process. Surely the security status of all other apps and updates in any OS depends on that of the package manager? Just as the F-Droid client can’t protect against vulnerabilities in the underlying OS. What am I missing here?
How much hassle is it for the app updates process to first check the current version of the client, and if it’s not the latest in the repo, update that first and restart? Then automatically check for updates to other apps.