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?