Das verlinkte Zitat verstehe ich so, dass man App faken könnte und dann trotzdem mit der reproduzierbaren Signatur signieren könnte. Und das ist auch das, was ich oben meinte/geschrieben habe. Sonst müsstest du mir erklären, was die Aussage dieses Satzes ist.
Eine App könnte man nur faken, wenn die Anwendung (ohne Signatur) bitgenau reproduziert werden konnte, also der gleiche Quellcode für beide Apps (Entwickler- und F-Droid-Version) verwendet wurde. Sobald das Ergebnis unterschiedlich ist, wird keine App gebaut veröffentlicht.
Das Problem ist, dass in der „Entwickler-Signatur“ Dinge eingebettet sein können, die dann ausgeführt werden, weil diese „Entwickler-Version“ letztendlich auf den Endgeräten landet und sich eine App anders verhalten könnte. Folglich muss man dem Entwickler vertrauen, dass in der Signatur tatsächlich nur die Signatur ist und nichts anderes.
Ich versteh noch nicht so ganz das Problem. Muss man dem Entwickler nicht eh vertrauen?
Grundsätzlich schon. Je nach „App-Store“ gibt es verschiedene „Bereiche“. In erster Linie, ob die App tatsächlich das tut, was sie soll. Dieser „Vertrauensvorschuss“ wird von keinem Store abgenommen. Ein weiterer Bereich: „Wurde der unveränderte Quellcode verwendet?“ (lösbar durch reproduzierbare Builds oder die „normalen“ F-Droid Builds)
Konkret in diesem Fall, muss man dem Entwickler vertrauen, dass in der Signatur kein böswilliger Code versteckt ist. Allerdings ist die Erwartung bei reproduzierbaren Builds, dass immer exakt die gleiche App erzeugt wird und genau hier liegt das Problem: Die Signatur des Entwicklers wird als gültig erkannt, obwohl sie es eigentlich nicht sein sollte.
F-Droid hat vor kurzem bekannt gegeben, dass die Sicherheit in diesem Jahr mit im Fokus steht:
In 2025 we are thrilled to begin working on a grant funded by the Open Technology Fund. This grant will help us maintain F-Droid and focus on critical infrastructure work that was often overlooked, due to lack of consistent funding in the past. We’ll be working on improving the resilience and security of our systems, ensuring that F-Droid continues to serve as a reliable, open-source app distribution platform for years to come. There will be an official announcement article coming soon.
Vielleicht besteht ja Hoffunung! Darüber hinaus wurde die Schwachstelle ja direkt kommuniziert und vom Team registriert.
3 „Gefällt mir“
Leider reden hier immer bei Fdroid viele mit die nicht verstehen was Fdroid ist.
Obtainium ist ein spezieller Downloadmanager der dir hilft Apps aus verschiedenen Bezugsquellen herunterzuladen. Es ist keine Bezugsquelle.
Fdroid ist eine Bezugsquelle für Apps die speziell geprüft wurden.
Die Fdroid App ist ein Downloadmanager um Apps von Fdroid runzerzuladen.
Ein Repo ist ein Hilfskonstrukt um mit der Fdroid App nicht von Fdroid stammende Apps aus anderen Bezugsquellen bequemer herunterzuladen. Es gibt z.B. ein Total Commander Repo um die nicht Playstore Version runterzuladen. Der TC ist weder Open Source noch irgendwie von Fdroid geprüft.
Fazit: Die Sicherheit die Fdroid bietet gibt es nur bei Apps die man direkt von Fdroid bezieht.
Ich finde den Ton ziemlich ungelungen, natürlich weiß ich was F-Droid ist, sonst würde ich mir keine Sorgen machen.
Man kann sich natürlich über die Begrifflichkeiten streiten, Obtainium bezieht für mich die App bei Quelle xy, damit vermittelt Obtainium die APK-Dateien was es im weiten Sinne auch zu einer Bezugsquelle macht.
Falls es für Verwirrung gesorgt haben sollte: es ging viel mehr darum die Frage zu klären ob die APK von einem Entwickler Repository (Github, Gitlab etc.) nennenswerte Vor- oder Nachteile gegenüber der APK vom F-Droid Repository mit sich bringt.
1 „Gefällt mir“
Vorteil (Entwickler Repository):
- schnellere Updates
Nachteil:
- keine Verknüpfung zum Sourcecode
Wer signiert ist mir eigentlich egal. Seh das weder als Vor- oder Nachteil.
Open Source ist zwar gut, bringt aber nix wenn man nicht weiß ob der Code verwendet wurde.
1 „Gefällt mir“
- Builds so wie sie vom Entwickler vorgesehen sind
- Dependencies ggf. aktueller
- Separierung von Build und Signierung möglich
- Keine zusätzlichen Trusted Parties
- Schnellere Updates
- Ggf. sichere Buildserver und Offline-Signierung möglich
- Keine falsche Sicherheit durch F-Droid checks, da F-Droid fast nur automatisiert checkt und die Wahrscheinlichkeit bösartiges Verhalten zu detektieren ziemlich gering ist bei diesen Checks
Nachteile:
- Keine Sicherheit, dass Binärdatei dem Source-Code entspricht (außer bei reproduzierbaren Builds)
- Keine automatisierten Checks durch F-Droid (Tracker-Signaturen, AV)
Dependencies für die App selbst? Die sind im Repository gepflegt und bei beiden gleich: https://github.com/spacecowboy/Feeder/blob/master/gradle/libs.versions.toml
Der Punkt ist auch nicht ganz richtig. Ich weiß ja nicht auf welchen Geräten der Entwickler das Build macht und ob die auf dem aktuellen Stand sind. Ich weiß auch nicht ob die Entwickler-Geräte mit Malware infiziert sind oder nicht. Zumindest bei F-Droid weiß ich, dass das Einmal-Container sind also vor dem Build erzeugt und nach dem Build entsorgt werden.
Diese Sicherheits-Checks fallen bei allen Stores regelmäßig durch, da würd ich mich nirgends drauf verlassen.
Hi @Chief
mal aus ernsthaftem Interesse: Wie beziehst Du denn konkret Deine Software? Auf verschiedenen Geräten/OS? D.h. z.B. sowohl Smartphone mit einer Android Variante (GrapheneOS?) als auch Desktop-PC (Desktop, Workstation, Notebook) mit einem „großen“ OS (wie Apple macOS, Microsoft Windows, Linux, BSD)?
Hallo, kann mir hierzu bitte jemand eine Quelle nennen oder mir das erklären?
Warum ist der Aurora-Store mit eigenem Google-Account sicherer als über den anonymen Zugang? Und worin besteht überhaupt das Risiko?
Dann gehe ich mal in Vorleistung:
- Android i.w.S. (d.h. sowohl Geräte mit Stock als auch mit GrapheneOS oder iodé OS):
- F-Droid (so weit wie möglich — allerdings ohne zusätzliche Repositories)
- Google Play Store (Stock, GrapheneOS) bzw. Aurora Store (iodé OS)
- keine manuellen APKs oder per Obtainium!
- Linux (openSUSE):
- Repository-Management von openSUSE
- FlatHub (inkl. automatische Updates)
- Snap (inkl. automatische Updates)
- AppImage (ohne automatische Updates!)
- manuelle Downloads
- Microsoft Windows:
- Chocolatey (so weit wie möglich!)
- manuelle Downloads
- kein Microsoft Store!
- Apple macOS:
- manuelle Downloads (ich habe dort insgesamt nicht viele Anwendungen, mein persönlicher Aufwand für manuelle Downloads ist sehr überschaubar)
- bisher kein Homebrew (aber ich habe es im Fokus)
- kein Apple Store!
Bei manuellen Downloads gibt es manchmal einen integrierten Updater. So haben bei mir unter Apple macOS die Anwendungen Mozilla Firefox und Thunderbird einen integrierten Updater und mussten nur einmalig installiert werden, machen dann aber selbst Updates.
Interesssant zu lesen, wie kann man das überprüfen?
Also ob die installierten Apps richtig signiert wurde.
Ich habe festgestellt, das eine App aus eine Repo nicht mehr die Signierung hatte und das update verweigert wurde . Im original Repo von F-Droid stimmte die Signierung und konnte ein update erhalten.
- Apple macOS:
…
- kein Apple Store!
Danke für die Auflistung @ynMBLn4y!
Ist ein manueller Download unter iOS-Mobilgeräten eigentlich auch möglich? Oder gibt es dort mittlerweile endlich mal eine Alternative zum Apple-Store?
Siehe z.B. Apps über alternative App-Verteiler in der Europäischen Union installieren.
Wenn man mit einer Suchmaschine z.B. nach „sideloading“ oder „alternative Stores“ sucht, kann man wohl ein paar Alternativen zum Apple Store finden (hier ohne explizite Bespiele).
Ja, seit neuestem gibt es auch die Möglichkeit des Sideloadings. Ob es mittlerweile auch andere Stores gibt, weiß ich nicht.
Danke @DwainZwerg!
Das liest sich ja ziemlich unkomfortabel. Wobei z.B. für ein Pendant von Netguard/RethinkDNS mit ähnlichem Funktionsumweg würde sich die Mühe lohnen.
Das würde mich auch nochmal interessieren.