Thunderbird 102 Release trotz leichten und schweren Fehlern

„Security geht vor“, aber es gibt Grenzen. Diese wurden beim Thunderbird 102 Update gestern wohl leicht überschritten.

Thunderbird 102 Release trotz leichten und schweren Fehlern

Auf der Fedora Developer Mailingliste ist ein interessanter Beitrag gelandet, in dem sich über das Thunderbirdupdate 102 ausgelassen wird. Die näheren Umstände spielen für den Beitrag keine Rolle, in Kürze: viel zu schnell, keine ausreichenden Test, Änderungen angemahnt.

Wichtig ist eine der Antworten eines Benutzers, der dank des Updates einige Konten und Filter verloren hat. Für ihn kam nur ein Downgrade + Backup in Frage. Ich hatte vor dem Lesen dieses Postings bereits eiN Ticket auf gemacht, weil bei mir andere Probleme aufgetreten sind:

Der erste Start erfolgte in English, obwohl alle Sprachpakete vorhanden waren, was ein anderes Problem für sich darstellt, denn diese hatte ich schon das letzte mal gelöscht, als die ungefragt alle wieder installiert wurden.

Dummerweise lassen sich diese Pakete nicht löschen. Thunderbird empfiehlt dazu den „Safe-Mode“ zu benutzen, also ohne Addons usw. . Das bringt und zum nächsten Problem:

Der Safe-Mode geht nicht

Ja, Leute Ihr hab richtig gelesen: Der eben noch empfohlene Muß-Immer-Starten-Modus geht nicht.

Die Anwendung startet zwar, aber nach dem Laden des Caches und der Konten passiert rein gar nichts mehr. Es kommt keine GUI, ergo kann man nichts machen. Neue Thunderbird starten dann natürlich auch nicht, weil schon eine Instanz läuft 😉 Da auch Strace nichts brauchbares geliefert hat, ist das jetzt Sache der Thunderbird Devs.

Ironischerweise oder „Zum Glück“ startet Thunderbird im Normalmodus noch, so daß es kein Totalausfall ist.

Bugreports bei Fedora und Mozilla sind raus und ich wette bei den anderen Distros sieht es nicht besser aus.

Die ganzen Quickpushes wurden übrigens nötig, weil Thunderbird < 102.0.2 eine schwere Sicherheitslücke hat, die dringend geschlossen werden mußte. Aber was nutzt es dem User, wenn er sicher ist, aber die Anwendung nicht mehr läuft? Zum Glück lief das Update es bei den Meisten mit kleinen oder gar keinen Fehlern durch, aber das in unter 24h schon 2 auf der Dev-ML über Fehler berichten, ist schon erstaunlich, weil das sonst nicht passiert.

Pinephone: kleines Fedora Statusupdate

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!

Synapse 1.51+ mit schwerem Empfangsfehler

Marix Synapse Implementierung hat einen schweren Bug in den Versionen 1.51 und 1.52, der dazu führt, daß keine Nachrichten mit bestimmten Eigenschaften ( Verschlüsselung ) beim Empfänger ankommen.

Synapse 1.51+ mit schwerem Empfangsfehler

Kurios macht diesen Fehler, daß er nur bei Externen Nachrichten auftaucht. Schickt man intern Nachrichten von einem Account zum Anderen, kommen die Nachrichten trotzdem an.

Um festzustellen, daß Ihr betroffen seid, reicht es im Log des Homeservers nach diesen Fehlermeldungen zu suchen:

2022-02-09 00:00:41,933 - synapse.federation.transport.server.federation - 114 - ERROR - PUT-34443 - 'dict' object has no attribute 'edu_type'
Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/twisted/internet/defer.py", line 1661, in _inlineCallbacks
    result = current_context.run(gen.send, result)
StopIteration: 0

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/twisted/internet/defer.py", line 1661, in _inlineCallbacks
    result = current_context.run(gen.send, result)
StopIteration: {'ed25519:a_iiuD': FetchKeyResult(verify_key=<nacl.signing.VerifyKey object at 0x7fc8a5af6d90>, valid_until_ts=1644443665400)}

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.9/site-packages/synapse/federation/transport/server/federation.py", line 101, in on_PUT
    device_list_updates = [
  File "/usr/lib/python3.9/site-packages/synapse/federation/transport/server/federation.py", line 104, in <listcomp>
    if edu.edu_type in DEVICE_UPDATE_EDUS
AttributeError: 'dict' object has no attribute 'edu_type'

Die Folge, Nachrichten mit diesem Attribute kommen nicht an, weil es einen GEHEIMEN! Defaulteintrag zu einem nicht standardmäßig konfigurierten Logger gibt! Ja, richtig gelesen: Weil die Nachrichten geloggt werden sollen, kommen Sie nicht an, weil das Pythonscript vorher crasht.

Die Lösung für das Problem

Die Lösung ist sehr einfach, was man auch in diesem Commit nachlesen kann:

Öffnet die Datei log_config.yaml und ändert Sie so:

loggers:
       synapse:
            level: ERROR
            handlers: file

       synapse.8631_debug:
            level: ERROR

Danach Synapse neustarten und das war es schon. Wenn Ihr betroffen ward und kein scheues Rehlein, sondern ein Matrix Hengst seid, bricht dann leider ein wahrer Sturm über Euren Server ein, weil alle anderen Server Euch gern die verpassten Nachrichten zustellen wollen. Kurzfristige Loadwarnungen sind zu tolerieren 😉