signal-desktop Paket missing

h^2

h^2

hat ne Keule +1
Mein signal-desktop streikt seit dieser Woche, weil es so lange nicht aktualisiert wurde. Tatsächlich scheint es keine Pakete mehr zu geben. Früher waren sie zumindest im quarterly-branch, aber auch da finde ich keine mehr.

Also habe ich versucht es aus den Ports zu bauen. Das hat meine 12 Kerne ca. 5 Stunden ausgelastet und ist dann gefailt, bei noch nichtmal 50% Fortschritt. Selber bauen ist also auch nicht feasible.

Ich weiß, dass dieser ganze Electron-Stack ziemlicher Rotz ist, aber ich brauche Signal wirklich, und ich bin überrascht, dass es bei FreeBSD anscheinend nicht genug Bedarf gibt, dass das vernünftig paketiert wird... wie macht ihr das?
 
Passiert ab und an. Signal hat viele Abhängigkeiten, da ist die Chance groß, dass es mal nicht geht.
Bei mir hats gestern auch nicht gebaut (aktueller Ports tree);

Wegen libxslt muss man make mit DISABLE_VULNERABILITIES=yes aufrufen, es scheiterte aber dann trotzdem an einem nicht vorhandenen
gettext-1.07.tar.gz als Abhängigkeit, das gabs in keinem Repository.

Passiert ab und an, wg verschiedener Abhängigkeiten; meist geht es nach ein paar Tagen des wartens dann aber wieder.

Ich bau immer ein Package draus - und schau ab und an, wenns auf Linux ein Update gab, dann versuch ich ein neues Package zu bauen - solange nutz ich das vorige weiter.

Da ich aktuell kein FreeBSD als Desktop nutze ist es für mich erstmal kein Problem, für andere vermutlich schon.
Weiß aber auch nicht, ob man ältere Pakete (aber neuere als deines) noch irgendwo downloaden kann?
 
Harry schrieb:
Unter Linux nutze ich inzwischen Flare für signal https://mobile.schmidhuberj.de/flare

Sollte es auch für FreeBSD geben?
Zum Vergrößern anklicken....
Ja gibt es. https://www.freshports.org/net-im/flare/ Probiert habe ich ihn aber auch noch nicht. Kein Electron ist allerdings ein Pluspunkt. Eine infoffizielle App kann allerdings auch Fehler in der Krypto haben und nicht so sicher sein wie die der offizielle Client. Hat alle Vor- und Nachteile. Ich behalte Flare mal im Auge.
 
Das ist absolut richtig, der Entwickler warnt auch davor das es potentiell unsicherer sein könnte. Je nach Szenario kann das relevant sein, in meinem Fall hängt nicht mein leben davon ab wenn doch jemand mitlesen kann.
 
Harry schrieb:
Das ist absolut richtig, der Entwickler warnt auch davor das es potentiell unsicherer sein könnte. Je nach Szenario kann das relevant sein, in meinem Fall hängt nicht mein leben davon ab wenn doch jemand mitlesen kann.
Zum Vergrößern anklicken....
Die Gefahr könnte ja auch sein das durch eine böse nachricht dein komplettes System oder zumindest dein FreeBSD user komprommitiert wird
 
CommanderZed schrieb:
Die Gefahr könnte ja auch sein das durch eine böse nachricht dein komplettes System oder zumindest dein FreeBSD user komprommitiert wird
Zum Vergrößern anklicken....
Das sollte aber auch beim offiziellen Client/App denkbar sein. Man sollte da auch im Hinterkopf behalten das Signal in den USA ansässig ist und Amazon als Grundlage nutzt. Von daher ist zu vermuten das ein Player wie Signal mitlesen ermöglichen muss. Nur um das einmal im Hinterkopf zu behalten. Keiner kann prüfen ob die öffentliche Quelltext auch tatsächlich so für den offiziellen Build genutzt wird.
 
Harry schrieb:
Das sollte aber auch beim offiziellen Client/App denkbar sein.
Zum Vergrößern anklicken....

Der offizielle Client ist für alle Plattformen Open Source, inklusive der Desktop-Version.

Der Entwickler von Flare schreibt selbst:

This application will probably worsen the security compared to official Signal products.​

Ich glaube, das spricht für sich.

Harry schrieb:
Man sollte da auch im Hinterkopf behalten das Signal in den USA ansässig ist und Amazon als Grundlage nutzt. Von daher ist zu vermuten das ein Player wie Signal mitlesen ermöglichen muss.
Zum Vergrößern anklicken....

Signal hat Ende-zu-Ende-Verschlüsselung. Selbst wenn ein Server kompromittiert ist, ist der Inhalt der Nachrichten sicher. Man muss sich nur Sorgen um die Metadaten machen, aus denen man natürlich auch wieder Schlüsse ziehen kann.

Harry schrieb:
Nur um das einmal im Hinterkopf zu behalten. Keiner kann prüfen ob die öffentliche Quelltext auch tatsächlich so für den offiziellen Build genutzt wird.
Zum Vergrößern anklicken....

Du musst den offiziellen Build nicht nutzen, sondern kannst - wie in diesem Fall FreeBSD oder auch viele Linux-Distributionen - aus den Quellen bauen.
 
Harry schrieb:
Das sollte aber auch beim offiziellen Client/App denkbar sein. Man sollte da auch im Hinterkopf behalten das Signal in den USA ansässig ist und Amazon als Grundlage nutzt...
Zum Vergrößern anklicken....
Angeblich speichern sie nur genau zwei Daten: die der allerersten Anmeldung/Registrierung beim Signal-Dienst, samt Tel-Nr, und das Datum/den Zeitstempel der letzten aktuellen Anmeldung des Accounts mit dieser Nr. an den Signal-Dienst.

Gab wohl auch schon Vorladungen/Aufforderungen ("subpoena") seitens der Behörden, Daten rauszugeben, was sie dann auch taten - da halt angeblich dann nur die beiden Zeitstempel zur jeweiligen Tel-Nr.

Siehe zu dem ganzen Thema allerdings auch hier: Link

Andersrum gefragt: Wem könnte man dann überhaupt noch trauen?
Zuende gedacht würde das im Endeffekt bedeuten, jeder muss sich einen eigenen Messenger schreiben - alle anderen könnten schließlich Daten abschnorcheln.
Man dürfte da allerdings dann auch keine externen Abhängigkeiten einbinden - da hätte man dann ja wieder das Problem des Vertrauens in jemanden externen.

Lass grad einen make fetch-recursive im signal-desktop Folder laufen, das is eigentlich schon wahnsinn, was der alles an Abhängigkeiten lädt; wer legt dafür seine Hand ins Feuer?? (und vor allem: wer blickt das überhaupt noch - Gigabyteweise Abhängigkeiten, für einen Messenger!)

EDIT: überzähliges "würde" entfernt
 
Zuletzt bearbeitet:
turrican schrieb:
Andersrum gefragt: Wem könnte man dann überhaupt noch trauen?
Zum Vergrößern anklicken....
Genau. Und man weiss auch nicht, ob man der Gegenseite trauen darf. Schnorchelt das eigene oder das Smartphone der Gegenseite mit? Schnorchelt Windows den Signal-Desktop-Client mit (Stichwort "Recall")? Wenns um Leib und Leben geht, wuerde ich keine Kommunikation ueber Smartphone oder PC durchfuehren. Ansonsten ist es mir eher wichtig, dass meine Daten nicht durch KI oder zu Werbezwecken ausgewertet und meinem Profil zugeordnet werden.
 
turrican schrieb:
Bei mir hats gestern auch nicht gebaut (aktueller Ports tree);
Zum Vergrößern anklicken....
Jetz kommt er zwar über das gettext Problem (Paket scheints wieder zu geben), allerdings fällt er beim fetch-recursive schon wieder auf die Nase, weil er keine file locks durchführen kann (/usr/ports kommt bei mir per NFS, da meine VMs nur 10GB standardmäßig groß sind)?

Das is auch wieder neu, hatte ich vorher noch nie :confused:

ERROR: Failed to lock the build directory: No locks available
 
Columbo0815 schrieb:
Das Paket ist aktuell wieder als Latest-Package verfügbar. Allerdings habe ich weiterhin das Problem, dass es mit der Meldung "Render process is gone" crashed. Es gab dazu einen Bugreport https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290376 der jedoch geschlossen wurde. Hier läuft es nicht in einer Jail und crashed trotzdem.
Zum Vergrößern anklicken....

turrican schrieb:
Jetz kommt er zwar über das gettext Problem (Paket scheints wieder zu geben),
Zum Vergrößern anklicken....
... und deswegen sollten wir beim Thema bleiben :)
 
Auch die nun in den Latest-Packages verfügbare Version 7.80.0 crashed mit dem gleichen Fehler. Funktioniert sie bei euch? Nutzt ihr wayland oder X.org?
 
Bei mir läuft das neue Paket (X11).

Wenn man es auf Wayland nutzt (wer hat Wayland auf FreeBSD?), sollte, wie bei allen Electron-Apps, wahrscheinlich das Rendering manuell auf Wayland setzen.
 
Interessant. Ich nutze ebenfalls X11, aber funktionieren tut es nicht. Ich habe testweise ~/.config/Signal gelöscht und komplett neu eingerichtet/gekoppelt. Das Koppeln an sich funktioniert. Aber direkt beim Synchronisieren erhalte ich folgende Fehlermeldung:

1763977340104.webp
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben