@stefanjahn @marcelklehr @kuketzblog
Das offizielle F-Droid repository benutzt diese Funktion auch in ihren Metadaten um bei reproduzierbar gebauten .apk die Signatur des ursprünglichen Entwicklers zu erzwingen. Allerdings werden wie bereits erwähnt, alle .apk die im F-Droid repository sind, auf dem Server von F-Droid gebaut und dann entweder eine eigene Signatur, oder im Falle reproduzierbaren .apk die Signatur der Original-App angehängt.
@stefanjahn @marcelklehr @kuketzblog
In den Metadaten zu einem F-Droid-Repository kann ein öffentlicher Schlüssel hinterlegt werden, sodass auf dem Server nur noch .apk für eine bestimmte App akzeptiert werden, die mit diesem Schlüssel signiert sind.
Diese Signaturprüfung hat aktuell Fehler, die unter Umständen dazu führen könnte, dass in einem F-Droid repository .apk mit Signaturen sind, die dort laut Metadaten nicht sein dürfen.
@[email protected]
> Das Paradoxe an Systemen wie GrapheneOS ist, dass sie oft sicherer sind als die Standard-ROMs, die von Herstellern wie Google angeboten werden.
Uff. Das ist extrem subjektiv. Klassische Betriebssystem-Sicherheit ist bei ungefähr allen Android-basierten Systemen bereits extrem hoch (deutlich besser als was man so für Desktop nutzt). Inzwischen ist das auch kaum ein Problem, kritischer stattdessen ist Malware, die dem Nutzer sagt "gib mir Zugriff auf ...
@stefanjahn @marcelklehr @kuketzblog
Der schlimmstmögliche Angriff auf dem offiziellen F-Droid-Repository ist also nicht, wie von @kuketzblog behauptet, dass eine "manipulierte oder unsichere" .apk im offiziellen F-Droid repository landet, sondern nur, dass eine kaputte oder falsche Signatur an die reproduzierbar gebaute .apk angehängt wird.