precision
This commit is contained in:
parent
4aea6d9ddb
commit
b3d45d8912
@ -60,7 +60,7 @@ As a result of this philosophy, the main repository of F-Droid is filled with ob
|
||||
## 4. General lack of good practices
|
||||
The F-Droid client allows multiple repositories to coexist within the same app. Many of the issues highlighted above were focused on the main official repository which most of the F-Droid users will use anyway. However, having **other repositories in a single app also violates the security model of Android** which was not designed for this at all. As a matter of fact, the new unattended update API from Android 12 that allows seamless app updates for app repositories without [privileged access](https://f-droid.org/en/packages/org.fdroid.fdroid.privileged/) to the system (such an approach is not compatible with the security model) won't work with F-Droid. It should be mentioned that [Droid-ify](https://github.com/Iamlooker/Droid-ify/issues/20) is trying to figure out a way to make it work, although the underlying issues about the F-Droid infrastructure remain.
|
||||
|
||||
Their client also lacks **TLS certificate pinning**, unlike Play Store which does that for all connections to Google. Certificate pinning is a way for apps to increase the security of their connection to services [by providing the hashes](https://developer.android.com/training/articles/security-config#CertificatePinning) of known-good certificates for these services instead of trusting pre-installed CAs. This can avoid some cases where an interception (*man-in-the-middle* attack) could be possible and lead to various security issues considering you're trusting the app to deliver you other apps.
|
||||
Their client also lacks **TLS certificate pinning**, unlike Play Store which does that for all connections to Google. Certificate pinning is a way for apps to increase the security of their connection to services [by providing a set of public key hashes](https://developer.android.com/training/articles/security-config#CertificatePinning) of known-good certificates for these services instead of trusting pre-installed CAs. This can avoid some cases where an interception (*man-in-the-middle* attack) could be possible and lead to various security issues considering you're trusting the app to deliver you other apps.
|
||||
|
||||
It is an important security feature that is also straightforward to implement. See how GrapheneOS pins both root and CA certificates in [Auditor](https://github.com/GrapheneOS/Auditor) for their attestation service:
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user