1
0

rewording

This commit is contained in:
Wonderfall 2022-01-03 06:00:33 +01:00
parent 15a7cc365b
commit 9cc0e26ca3

View File

@ -16,7 +16,7 @@ Before we start, a few things to keep in mind:
## 1. The trusted party problem
To understand why this is a problem, you'll have to understand a bit about F-Droid's architecture, the things it does very differently from other app repositories, and the [Android platform security model](https://arxiv.org/pdf/1904.05572.pdf).
Unlike other repositories, F-Droid signs all the apps (at least in its main repository, we'll get back to it later) with app keys it always owns. A signature is a mathematical scheme that guarantees the authenticity of the applications you download. Upon the installation of an app, Android pins the signature across the entire OS (including user profiles): that's what we call a *trust-on-first-use* model since all subsequent updates of the app must have the corresponding signature to be installed.
Unlike other repositories, F-Droid signs all the apps (at least in its main repository, we'll get back to it later) with its own signing keys. A signature is a mathematical scheme that guarantees the authenticity of the applications you download. Upon the installation of an app, Android pins the signature across the entire OS (including user profiles): that's what we call a *trust-on-first-use* model since all subsequent updates of the app must have the corresponding signature to be installed.
Normally, the developer is supposed to sign their own app prior to its upload on a distribution channel, whether that is a website or a traditional repository (or both). You don't have to trust the source (usually recommended by the developer) except for the first installation: future updates will have their authenticity cryptographically guaranteed. The issue with F-Droid is that all apps are signed by the same party (F-Droid) which is also not the developer. You're now adding another party you'll have to trust, which isn't ideal: **the fewer parties, the better**.