Category Archives: Fedora

Pinephone: How to Fix Geary’s Libsoup Problem

Posted on by

Nachdem ich Euch gestern den Statusbericht geschrieben hatte, wollte ich mal mit Geary Emails lesen. Was für eine fatale Entscheidung 🙁

Pinephone: How to Fix Geary’s Libsoup Problem

Was braucht man zum Lesen von Emails? Ein Emailprogramm! Also nehmen wir doch das seit zwei Jahren installierte, konfigurierte und funktionierende Geary … startet nicht … öhm ?!?!

Dem Journal seine Geheimnisse zu entreißen war auch nicht so einfach, weil Geary nicht als geary Unit logged, sondern als „geary-autostart.desktop[4159]“ wobei die Zahl die PID des Prozesses ist die, na wer räts, flexibel ist. Hallo?!?! Er hat denn diesen Blödsinn jetzt wieder verzapft!

Kommen wir zum Problem

geary-autostart.desktop[4159]: ![err] 18:09:01.0248 libsoup:libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.

Wahnsinnsmeldung, aber tatsächlich zutreffend. Es gibt zwei Versionen von der LibSoup: 2.4 und 3.0.

Libsoup is an HTTP library implementation in C. It was originally part of a SOAP (Simple Object Access Protocol) implementation called Soup, but the SOAP and non-SOAP parts have now been split into separate packages.

1/3 aller Apps setzen noch auf 2.4, die anderen 2/3 setzen auf die Version 3.0 der Lib. Offensichtlich ist es nicht erlaubt, beide Versionen gleichzeitig in einem Programm zu benutzen, was ja auch Sinn macht, weil so ein App-Entwickler leicht mal den Überblick über seine Ressourcen verliert und dann passieren ganz komische Dinge.

Es gibt es nur ein kleines Problem:

# ldd /usr/bin/geary | grep soup
libsoup-2.4.so.1 => /lib64/libsoup-2.4.so.1 (0x0000007f80910000)

… kleine Pause, damit sich die Info bei Euch setzen kann…

Ok, also Geary nutzt nur die 2.4, kann aber nicht sein, weil die Meldung sagt ja, daß beide Versionen gesichtet wurden. Da müssen wir wohl mal mit strace nachsehen, was da abgeht:

pine@fedorapine ~]$ strace -f geary 2>&1 | grep soup
openat(AT_FDCWD, „/lib64/libsoup-2.4.so.1„, O_RDONLY|O_CLOEXEC) = 3
[pid 5045] openat(AT_FDCWD, „/usr/lib64/evolution-data-server/libsoup-3.0.so.0“, O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
[pid 5045] openat(AT_FDCWD, „/lib64/libsoup-3.0.so.0„, O_RDONLY|O_CLOEXEC) = 21
[pid 5045] write(2, „![err] 18:13:40.0262 libsoup:lib“…, 121![err] 18:13:40.0262 libsoup:libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.) = 121

Wie der erfahrene Leser sofort sieht, sind hier zwei Prozesse beteiligt, der Hauptprozess ist Zeile 1, also Geary selbst:

openat(AT_FDCWD, „/lib64/libsoup-2.4.so.1„, O_RDONLY|O_CLOEXEC) = 3

ein Subprozess mit PID 5045 sind die anderen:

[pid 5045] openat(AT_FDCWD, „/usr/lib64/evolution-data-server/libsoup-3.0.so.0“, O_RDONLY|O_CLOEXEC) = -1 ENOENT (Datei oder Verzeichnis nicht gefunden)
[pid 5045] openat(AT_FDCWD, „/lib64/libsoup-3.0.so.0„, O_RDONLY|O_CLOEXEC) = 21
[pid 5045] write(2, „![err] 18:13:40.0262 libsoup:lib“…, 121![err] 18:13:40.0262 libsoup:libsoup2 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported.) = 121

Jetzt ist eigentlich schon klar, daß Geary tatsächlich nur die 2.4 lädt, aber irgendeine Lib/App/Plugin das Nachgeladen wird, will die 3.0 laden.

Da stellt sich jetzt die Frage, wie man das rausbekommt, weil Geary schon 148 Libs lädt und was das an Plugins lädt, steht nur im Source drin und ist vermutlich auch hochgradig davon abhängig, was das jeweilige Plugin vorhat.

Langer Rede kurzer Sinn

Um das rauszubekommen, mußte eine radikale Entscheidung her:

chmod 000 /lib64/libsoup-3.0.so.0.0.5

Eigentlich als Notmaßnahme gedacht um zu sehen, ob Geary starten würde, wenn man die Lib aus dem System entfernt, brachte das dann alles nötige ans Licht. Geary startet nämlich „normal“, aber eine als Adressbuch genutzte Komponente namens „folks“ , die wollte nicht mehr.

libfolks is a library that aggregates people from multiple sources (e.g. Telepathy connection managers and eventually evolution data server, Facebook, etc.) to create meta-contacts.

Das machte sich dann im Journal so bemerkbar:

Aug 17 18:55:01 fedorapine geary[5678]: *[wrn] 18:55:01.0337 folks:backend-store.vala:768: Failed to load module from path ‚/usr/lib64/folks/26/backends/eds/eds.so‘: libsoup-3.0.so.0: Kann die Shared-Object-Datei nicht öffnen: Keine Berechtigung
Aug 17 18:55:01 fedorapine geary[5678]: *[wrn] 18:55:01.0369 folks:backend-store.vala:768: Failed to load module from path ‚/usr/lib64/folks/26/backends/bluez/bluez.so‘: libsoup-3.0.so.0: Kann die Shared-Object-Datei nicht öffnen: Keine Berechtigung
Aug 17 18:55:01 fedorapine geary[5678]: *[wrn] 18:55:01.0377 folks:backend-store.vala:768: Failed to load module from path ‚/usr/lib64/folks/26/backends/ofono/ofono.so‘: libsoup-3.0.so.0: Kann die Shared-Object-Datei nicht öffnen: Keine Berechtigung
Aug 17 18:55:01 fedorapine geary[5678]: *[wrn] 18:55:01.0418 folks:Failed to find primary PersonaStore with type ID ‚eds‘ and ID ’system-address-book‘.
Aug 17 18:55:01 fedorapine geary[5678]: Individuals will not be linked properly and creating new links between Personas will not work.
Aug 17 18:55:01 fedorapine geary[5678]: The configured primary PersonaStore’s backend may not be installed. If you are unsure, check with your distribution.

Jetzt haben wir die Ursache für das Problem gefunden, aber wie fixen wir das jetzt erstmal temporär, bis Geary auf LibSoup-3 umgestellt ist?

How to Fix … auf die ganz harte Tour

Wir brauchen…

einen Gearywrapper
die Hilfe von Sudo
und ein gutes Gedächtnis,

weil das dürft Ihr nach jedem Geary oder LibSoup3 Update nochmal anpassen 🙁

SUDO

Wir tragen in die /etc/sudoers entweder direkt oder über das sudoers.d Verzeichnis folgendes ein:

# cat /etc/sudoers | grep geary
@include /etc/sudoers.d/gearywrapper.conf

# cat /etc/sudoers.d/gearywrapper.conf
pine ALL = (root) NOPASSWD: /usr/bin/chmod

ACHTUNG: damit darf der Pineuser alle Files chmodden die er will, oder die ein Angreifer will, aber nie ändern können sollte. Anders gehts aber erstmal nicht.

Der Geary-Wrapper

In die Datei /usr/local/sbin/gearywrapper muß das rein:

#!/bin/bash

sudo /usr/bin/chmod 000 /lib64/libsoup-3.0.so.0.0.5
geary –gapplication-service
sudo /usr/bin/chmod 755 /lib64/libsoup-3.0.so.0.0.5

dann chmod 755 /usr/local/sbin/gearywrapper ausführen.

Das Geary-Desktopfile

Das File /usr/share/applications/geary-autostart.desktop muß so geändert werden:

#TryExec=geary
#Exec=geary –gapplication-service
Exec=/usr/local/sbin/gearywrapper

Das File /usr/share/applications/org.gnome.Geary.desktop kann so geändert werden, aber nicht alle Einträge sind wichtig, die ersten 2 reichen:

TryExec=/usr/local/sbin/gearywrapper
Exec=/usr/local/sbin/gearywrapper %U
Exec=/usr/local/sbin/gearywrapper mailto:
Exec=/usr/local/sbin/gearywrapper –new-window

Ab jetzt startet Geary aus dem AppGrid wieder \o/ nur das Adressbuch funktioniert nicht mehr ganz so umfangreich wie es sollte, aber zumindest kann man wieder Emails lesen und schreiben.

Update: 13:46 Uhr – fixed Geary 40.0-9 released

Fedora Maintainer Kalev Lember hat für die älteren Versionen von Geary, und natürlich die Rawhideversion, einen Upstreampatch in den Fedora Build integriert und mit dem Paket ab Version 40.0-9, ist der Fehler behoben und Geary startet auch mit dem aktuellen folks und Evolution Unterbau. Auf den obigen Workaround hingewiesen, entfleuchte Kalev der folgende Kommentar: „Hah, fun hack 🙂“ . Es war zwar echt nervig das Problem zu isolieren, aber der Workaround war wirklich spaßig 😀

Pinephone: kleines Fedora Statusupdate

Posted on by

Weil mein Android J3 wohl einen defekten Kondensator im Empfangsschwingkreis hat, kommt Ihr jetzt in den Genuss eines Pinephone Statusreports 🙂

Pinephone: kleines Fedora Statusupdate

Fangen wir mal damit an:

Wenn Eurer Telefon den Funkmast mal findet und meisten gar nichts mehr finden will, dann ist entweder der Standort gut abgeschirmt, oder der Empfänger im Modem des Handies defekt. So oder so, reparieren lohnt nicht, auch wenn das Ersatzteil nur wenige Cents kosten würde, weil man den (wahrscheinlich) defekten SMD Kondensator erst aufwendig finden muß. Da sind die Lohnkosten leider zu hoch für 🙁

Gut, wenn man ein voll installiertes und konfiguriertes Pinephone rumliegen hat. Erstens kann man damit leicht testen, ob der Funkmast defekt ist, oder der Empfänger hin ist. Weniger gut ist, wenn Deine Pinephone DE in eine Endlosschleife wechselt, sobald Du mal rumswipst 🙁

Phosh 0.20.0

Phosh 0.20.0 hat einen, zum Glück behebbaren Bug, daß es in genauso eine Endlosschleife geht, wenn man den Taskmanager zweimal aufrufen will. Das Toppanel bekommen man zwar noch runter geswiped, aber rauf geht nichts mehr und Sound + Volumetasten waren auch nicht mehr reaktiv.

Um rauszufinden, ob Ihr den Fehler selbst beheben könnt, gebt mal als Pineuser per SSH ein:

$ gsettings get org.gnome.desktop.interface enable-animations

Wenn da „false“ rauskommt, dann seid Ihr mit dem Fix hier:

$ gsettings set org.gnome.desktop.interface enable-animations true
$ systemctl restart phosh

schnell auf der Gewinnerseite 😉

Pinephone powered down

Natürlich war die Zeit, als der Bug bei mir aktiv war nicht ganz ohne positiven Nebeneffekt, weil wir gleich das nächste Problem identifizieren konnten:

Wenn phosh oder phoc in so einer Endlosschleife festhängen, können Sie auf Tastenevents nicht mehr reagieren. Da greift dann der systemd-logind ein und behandelt das Event so, wie es in /etc/systemd/logind.conf festgelegt ist. Drückt man in so einer Situation auf die Powertaste, denn fährt der logind das System einfach runter! Das will man natürlich nicht, sondern Systemd soll Phosh neustarten, damit das wieder reagiert.

Das erreichen wir so:

Wir legen eine Datei namens /etc/systemd/logind.conf.d/ignore-power-key.conf an und schreiben da rein:

[Login]
HandlePowerKey=ignore

Dann..

$ systemctl restart systemd-logind phosh

und das Problem sollte weg sein. Da wir das erst heute zusammen mit Purism rausgefunden haben, muß ich noch abwarten wie sich das konkret auswirkt. Da aber min. eine andere Distro das auch schon per Default so blockiert, wird es wohl gehen.

Der aktuelle Stromverbrauch

Heute Nacht bin ich bei ca. 8h DeepSleep des Handies auf folgende Batterydauer bis zum Aufladen gekommen:

4% battery ( 84%->80%) in 8h im DeepSleep

ergibt 12% pro Tag, ergibt eine Woche Deepsleep, bevor man es wieder Aufladen muß. Dabei wird das Handy nicht ganz leer, was gut für den Akku ist. Allerdings verkürzt sich das dramatisch, wenn man es einschaltet 😀

 

Inkorrektes Portswitchen beim Telefonieren

Ihr wisst, daß es im Pinephone 2 Lautsprecher gibt, den zum Telefonieren ( internal Earpiece ) und den Lautsprecher ( Speaker ). Beim Telefonieren ist mir ausgefallen, daß der Callsd mal wieder die Profile nicht richtig schalten würde ( Default <-> Phone ) . Dem war aber nicht so, weil bei den Ports lediglich die falschen Ausgabegeräte eingestellt waren. Nachdem ich das im Pulseaudio-Lautstärkeregler korrekt eingestellt hatte, sprang das Pine wieder zwischen Telefonbetrieb und Lautsprecher, für alles andere, hin und her.

„Sicherheitsproblem“ für den Einen, „paßt schon“ für den Anderen

Im Lockscreen von Phosh kann man ohne Authentifizierung WLAN, Bluetooth und Mobile Daten abschalten. Einer kleinen Umfrage gestern bei Linux am Dienstag, konnten wir entnehmen, daß sich die OSe dahingehen nicht ganz einige sind, ob es ein Sicherheitsproblem darstellt oder nicht. AOS 5+ ist z.b. der Meinung, daß darf man ohne Authentifizierung nicht, iOS war da anderer Meinung.

Ich denke, es ist ein Sicherheitsproblem, weil wenn ich z.b. einen Tracker installiert habe, der mein Telefon wieder finden soll, wenn es geklaut wird oder verloren geht, dann sollte der Dieb das nicht abschalten können. Ok, er könnte das Telefon komplett abschalten, aber sobald er es bootet, würde der Tracker das melden.

Der entsprechende Bugreport bei Purism wurde nicht sofort geschlossen, was bedeutet, meine Argumente scheinen gewirkt zu haben. Der Kompromissvorschlag sieht vor, daß es „sicher“ ausgeliefert wird, aber per Control-Center in den „unsicheren“ Modus geändert werden kann. So haben alle den Zustand, den sie möchten.

Keine CoreDumps mehr nach Update

Stand Vorgestern, 15.8.2022, stürzt Evolution beim Start nicht mehr ab, wenn man auf dem neuesten Softwarestand ist. Das Booten geht damit auch wieder deutlich schneller 😉

Verbesserungen zur Kenntnis genommen

Phosh 0.20.0, oder auch schon 0.19.x, haben im Lockscreen beim Angerufen werden eine deutliche optische Verbesserung erfahren. Das sieht richtig schick aus. Weiter so!

PVA: kleines Sicherheitsloch im IMAP Modul

Posted on by

Wie das so mit komplexer Software ist, CVE Meldungen sind quasi vorprogrammiert, aber einfache Programmierfehler tun es meistens auch 🙁

PVA: kleines Sicherheitsloch im IMAP Modul

Jetzt ist der Einschlagkrater durch die im PVA gefundene Sicherheitslücke nicht besonders groß, man müßte Ihn vermutlich mit der Lupe suchen, weil kaum wer von dem neuen Feature wußte und es ausprobiert hat, aber, zur Vermeidung gleichartiger zukünftiger Unfälle, soll die Lücke seziert und dokumentiert werden.

Was ist passiert?

In der MailConnection-Komponente, die macht die IMAP Verbindung auf, war ein Programmierfehler drin, der die verschlüsselte Verbindung zum IMAP Server unterband. Wer also die neue Funktion schon ausprobiert hat , muß mindestens auf diesen Commit updaten: 685ee5ecaa486006a0cee04cac763ee479160e6e

Hier der fehlerhafte Code:

Properties props = System.getProperties();
if ( m.secure == true ) {
       props.setProperty("mail.store.protocol", "imaps");
} else props.setProperty("mail.store.protocol", "imap");

Session session = Session.getInstance(props, null);
Store store = session.getStore("imap");
store.connect(m.servername, m.username, m.password);

Statt die laut Konfiguration (m.secure) gewünschte Verbindungsart „imaps“ zu wählen, zog es der Code vor, dann doch unabhängig davon „imap“ zu verwenden. Korrekt wäre diese Zeile gewesen:

Store store = session.getStore();

Was war die Ursache?

Als Ursache konnte „mangelndes Verständnis“ der Methode getStore(…) ausgemacht werden, um genau zu sein, wurde erwartet, daß es sich um den Unterschied zwischen „POP3“ oder „IMAP“ handelt, weil der Sicherheitslevel wurde ja vorher schon festgelegt, aber leider überschrieb der Aufruf diese Voreinstellung wieder.

Was müßt Ihr tun?

Im Repo ist das Update bereits enthalten, so daß alle die, die Automatische Updates einspielen, schon sicher sind.
Wer seinen PVA selbst baut, der muß einmal updaten und compilieren.

Wie wurde es gefunden?

Vor 11 Jahren, ja, einfach weiterlesen, entschied ich, daß meine POP3/IMAP Serverlogs von einer Software auf genau diese unverschlüsselten Verbindungen prüft und den Benutzer darüber informiert, daß er irgendwo eine unsichere Konfig hat. 11 Jahre lang habe ich keine Email erhalten, und jetzt rettet dieses kleine Script dem PVA den Arsch 😉

PS: Falls wer dachte, daß man im Github einfach mal so ein Security Advisory schreiben könnte, der hat das noch nie versucht und mir ist jetzt klar, warum so viele Projekte mit Lücken, keine Securityeinträge haben 🙁