{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiclssnz7455nj6h47a2arfmztakmmwqelgtpm3d24qustbcthh3s4",
    "uri": "at://did:plc:34cg4tn4iwemk3v5k3n3adwf/app.bsky.feed.post/3mjp6tbgzkkv2"
  },
  "path": "/t/new-versions-of-f-droid-need-install-priority-over-other-updates/34263#post_8",
  "publishedAt": "2026-04-17T12:44:50.000Z",
  "site": "https://forum.f-droid.org",
  "textContent": "> that malicious software has an opening to be installed before the F-Droid app itself is updated to prevent that.\n\nWhat exactly is the security concern here? Android pins the APK signer and enforces that update must be signed by the same private key.\n\nSo 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.**\n\nIf 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.\n\n> bug that makes it vulnerable to installing malicious software as updates\n\nI 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.\n\nThat 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.\n\nThe 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!\n\n> until you open the newly updated version of the client\n\nFrom 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.",
  "title": "New versions of F-Droid need install priority over other updates"
}