Liebe Community, es ist erneut #Followerpower gefragt. Ich möchte die Messenger-Matrix aktualisieren bzw. auf neuesten Stand bringen. Das geht mit vielen Augen einfacher. Wenn ihr etwas seht, was nicht mehr aktuell ist, dann einfach Nachricht an mich. Danke euch! ❤️ 👍
Hinweis:
bitte keine Anfragen für die Aufnahme weiterer Messenger
bitte nur Beiträge, die zur Aktualisierung der bestehenden Matrix beitragen
@kuketzblog
Ich habe den Bericht zum Thema Messenger in eurem Blog gelesen, hat mir sehr gut gefallen.
Ich wollte dazu anmerken, dass man Signal über die Calyx repo bei F-Droid installieren kann.
@kuketzblog
Zur Messengermatrix:
Es ist mir eine Ungereimtheit aufgefallen. Apps, die für iOS und Android verfügbar sind, erhalten ein "grün", wenn es sie bei F-Droid gibt. Apps, die es nur für iOS gibt, erhalten ein "rot", wenn es sie nur im App Store gibt. Für den iOS User ist die Zeile also grün, wenn es die App auch bei F-Droid für Android gibt, obwohl dieser Nutzer wie bei den reinen iOS Apps auf den App Store angewiesen ist.
@kuketzblog
In der Tabelle sieht es so aus, als könnte man Threema von #fdroid herunterladen. Dort gibt es aber kein Threema, falls ich es nicht übersehen habe.
@jo_nathan was wiederum heißt es gibt Threema praktisch nicht im F-Droid Store, da hat @Wanda eigentlich schon Recht. Die Threema haben sich bewusst für diesen Recht komplizierten Weg entschieden, was aber auch heißt du hast die sonst bei F-Droid üblichen Überprüfungen nicht und keine Garantie, dass das was du da installierst wirklich aus dem öffentlich verfügbarem Quelltext gebaut wurde...
@jr
Danke, das sind auch meine Bedenken. Ich traue mich auch selten, irgendwas herunterzuladen.
In diesem Fall wollte ich auch "nur mal gucken", z.B. was da geht ohne zu bezahlen. Also hab ich es lieber gelassen.
Bin schon froh, dass einige aus meinem Umfeld Signal haben, so dass ich als WhatsApp-Verweigerin nicht völlig isoliert bin 😄 @jo_nathan
(Kontext: Ich habe das F-Droid Repo bei Threema eingerichtet.)
Die Nutzung eines separaten Repositorys bei F-Droid hat drei Gründe:
Wir möchten den Signing-Key selber kontrollieren. Die Nutzer müssen uns als Entwickler ohnehin vertrauen. Das ist besser, als wenn sie uns und F-Droid vertrauen müssen. (1/3)
Wir bieten Reproducible Builds an (https://threema.ch/en/open-source/reproducible-builds), exakt um "sicherzugehen, dass die App aus dem öffentlichen Quelltext gebaut wurde". So wie unser Prozess umgesetzt ist, ist das nicht direkt mit der Art, wie F-Droid Reproducible Builds umsetzt, kompatibel.
@dbrgn@jo_nathan@Wanda hm naja weil Reproduzierbare builds eben allgemein als "Bit-by-Bit" identisch definiert sind und ihr hier (genauso wie Signal btw) scheinbar nur auf Ebene der entpacken APKs vergleicht
@jr@jo_nathan@Wanda das APK kann gar nicht ohne Entpacken verglichen werden, weil die Signatur dran hängt. Ohne Signing Key kann man kein bit-für-bit identisches APK generieren.
Wir werden aber voraussichtlich auf Verifikation mit apksigcopier wechseln, dann fällt schonmal das Custom Script weg. (1/2)
@dbrgn apksigcopier macht ja mehr oder weniger das, es prüft ob der Rest der App bit-by-bit identical ist, indem es die Signatur von einer auf die andere APK transplantiert und dann prüft man halt ob die Signatur weiterhin stimmt...
@jr@jo_nathan@Wanda die Haupt-Inkompatibilität ist, dass wir komplett in Docker builden, damit wir ein exakt reproduzierbares Environment haben. Gerade mit Native Libraries, die als Teil des Buildprozesses kompiliert werden, kann ein kleiner Unterschied in einer Dependency schon zu einem nicht reproduzierbaren Build führen.
Der F-Droid-Ansatz ist (soweit ich das verstehe): "Wir nutzen diese Version von Debian und hoffen, dass das Gleiche rauskommt." Das ist nicht sehr zuverlässig. (2/2)
@dbrgn nicht sehr zuverlässig ist relativ, letztendlich ist ja auch im Docker Image nichts anderes als irgend eine Linux Distro mit ein paar Paketen. Das F-Droid halt keine random Docker images für den Bau irgendwo her ziehen wird ist hoffentlich halbwegs nachvollziehbar, denn nur so ist es möglich zu garantieren, dass das Binary was hinten rausfällt wirklich FOSS ist...
@dbrgn Bei nativen libraries geht F-Droid aber meist den Ansatz die direkt aus dem Quelltext zu bauen, da Debian ja nicht die passenden kompilate für Android hat
@jr so wie ich die situation verstehe, enthält MapLibre referenzen auf nicht-freie GMS-klassen. die klassen werden aber nicht mitgeliefert. das heisst, zur laufzeit wird geschaut, ob GMS installiert ist. wenn nicht, wird der freie fallback verwendet.
das heisst, nach meinem verständnis enthält die app dann keine unfreie software. sie referenziert unfreie software, was egal ist, sofern diese nicht teil der app ist.
Updates müssen bei F-Droid manuell von einem Maintainer signiert werden. So kann es mehrere Tage dauern, bevor ein (potentiell sicherheitsrelevantes) Update released wird. Bei unserem Repo sind die Updates sofort verfügbar.
@dbrgn@jo_nathan@Wanda das ist tatsächlich ein Drawback an dem wir als F-Droid Team aber durchaus arbeiten. Zumindest für mich persönlich überwiegt aber das eindeutig FOSS durch F-Droids prüfung gegenüber den möglichst schnellen Sicherheitsupdates.
Btw wenn wir mit Vorlauf von sicherheitsrelevanten Updates erfahren haben, konnte F-Droid in der Vergangenheit zB bei Element (dem Matrix Client) durchaus solche Updates Recht schnell ausrollen...
@jr@jo_nathan@Wanda ah, ich habe gar nicht realisiert, dass du auch bei F-Droid mithilfst 🙂 Idealerweise könnten wir das gleiche reproduzierbare APK sowohl direkt via F-Droid wie auch (mit schnelleren Updates) via eigenem Repo publizieren. Ich kommentiere zu dem Thema deine andere Reply.
Add comment