Libreoffice: Das Spreadsheet of Death

Vor einigen Wochen fiel jemandem auf, daß sein PC jedes mal lahmte, wenn er im LibreOffice eine bestimmte Tabelle ansah und editieren wollte. Das Tabellenblatt war aber gar nicht so groß, wie man glauben könnte, aber es war …

Das Spreadsheet of Death

Was passiert mit einem Linuxsystem, wenn der Xorg-Serverprozess bei 100% ankommt? Es bleibt faktisch stehen. Wer das mal live mit Libreoffice auf einem Ryzen 1500X erleben will, der kann sich noch dies Dokument ziehen: Das Spreadsheet of Death Beispiel. Das richtige ist leider wegen Datenschutz nicht öffentlich verfügbar und war ein bisschen länger.

Die Ursache ist, daß der Spellchecker, also die Rechtschreibkorrektur, alle Feldinhalte immer und immer wieder prüft, für falsch betrachtet und dann mit einem neuen Antialising-Malframework einen blauen oder roten Krikkel unter den Feldeintrag zeichnet.  Das neue Framework ist aber so inperformant, daß der Xorg Prozess auf einem CPU Kern bei 100% Last arbeitet.

Bei jedem Scrollen geht die Rechtschreibkorrektur wieder von vorn los, was direkt zum zähesten PC Erlebnis ever führt.  In TOP sah das dann so aus:

[~]$ top -c -b -n 1 | head -n 20
top - 11:54:26 up  2:01,  1 user,  load average: 0,51, 0,28, 0,20
Tasks: 409 total,   2 running, 407 sleeping,   0 stopped,   0 zombie
%Cpu(s): 14,2 us,  2,1 sy,  0,0 ni, 83,0 id,  0,0 wa,  0,0 hi,  0,7 si,  0,0 st
MiB Mem :  15967,5 total,   5456,9 free,   5122,1 used,   5388,4 buff/cache
MiB Swap:   7810,9 total,   7810,9 free,      0,0 used.  10141,6 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   1957 root      20   0  857132 191608 150596 R 100,0   1,2   6:16.45 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/u+
   2452 marius    20   0 3841504 252908 104348 S   6,2   1,5   4:15.81 cinnamon --replace
  13809 marius    20   0  126080  10728   8724 S   6,2   0,1   0:01.11 ssh -C -Y xxx@yy.yy.yy.yy
  14410 marius    20   0  116004   4228   3412 R   6,2   0,0   0:00.02 top -c -b -n 1
      1 root      20   0  171508  15268   9792 S   0,0   0,1   0:04.67 /usr/lib/systemd/systemd --switched-root --syst+
      2 root      20   0       0      0      0 S   0,0   0,0   0:00.01 [kthreadd]
      3 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [rcu_gp]
      4 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [rcu_par_gp]
      6 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [kworker/0:0H-kblockd]
      7 root      20   0       0      0      0 I   0,0   0,0   0:03.58 [kworker/u16:0-kcryptd/253:0]
      8 root       0 -20       0      0      0 I   0,0   0,0   0:00.00 [mm_percpu_wq]
      9 root      20   0       0      0      0 S   0,0   0,0   0:00.08 [ksoftirqd/0]
     10 root      20   0       0      0      0 I   0,0   0,0   0:02.65 [rcu_sched]

Das wurde nicht nur über den Bugzilla von RedHat berichtet, sondern auch von anderer Seite an die Entwickler bei LibreOffice gemeldet. Daher gibt es jetzt, so gefühlt 4 Monate später, einen Bugfix:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=bdd149b1ff3d43b94cadc0d43365100c287c7639

Improve spell checking performance and impl. in several ways:
* do synchronous spell checking, avoiding an idle handler
* avoid continuous invalidations caused per-cell by spell-checking
* cache spell-checking information for a given SharedString to avoid repeated checking of frequently recurring strings.

 

Das mit dem Cache für gleiche Inhalte hätte man glaube ich bei Version 0.1 einbauen sollen, das ist nämlich naheliegend 😉

Jetzt fragt Ihr Euch, wieso berichte ich erst jetzt davon… Tja, „a maliciously crafted document can lead to a DOS like attack on linux“. Das wollten wir natürlich nicht noch fördern 😉  Es werden zwar nur die sichtbaren Zeilen geprüft, aber alle Spalten. Da jetzt der Patch vorliegt und verteilt wird, kann man es ruhig erzählen 🙂

Thunderbird 78.3.1 Update mit kleinen Themebugs

Das Update von Thunderbird 78.3 ist nicht ganz so gut gelaufen, wie es sollte.

Thunderbird 78.3.1 Update mit kleinen Themebugs

Das gestern von Fedora präsentiere Update auf Thunderbird 78.3.1 hat leider kleine Bugs bei der Themeimplementierung:

Das bekommt man, wenn man die Themes umstellt von Default -> Dark -> Light -> Default  🙂

Als Folge sind Highlights dann weiße Schrift auf weißem Hintergrund, auch bekannt als die ostfriesische Nationalflagge.

Beheben läßt sich das zum Glück ganz einfach: Theme auswählen und Thunderbird neustarten.

Und auch beim Layout des „Neue Email schreiben“ Fensters gibt es kleine, wenn auch nicht sofort ersichtliche Fehlinterpretationen von „Das soll so sein“ :

Ich glaube nicht, daß es soooo geplant war 😉

Ganz klar, die alte Version mit An:, CC: und BCC: untereinander war IMHO besser, wird aber vermutlich ein ähnliches Verhalten gehabt haben. Der Fehler, wenn man so will, ist hier eigentlich, daß man es überhaupt soweit aufziehen kann, obwohl die UI Elemente das gar nicht nötig haben. Da fehlt so etwas wie ein max-height: im CSS 😉

Was man in den Bildern jetzt nur ganz schlecht zu erkennen ist, daß sich auch der Default Icon Satz geändert hat. Er entspricht jetzt einem HIGH-Contrast Iconsatz für sehbehinderte Menschen. Das ist nicht nur mir ausgefallen. Auch dies wurde Thunderbird als Bug gemeldet, denn im System ist „Gnome“ als Iconsatz eingestellt und da hat sich TB bislang auch dran gehalten.

Der neue Iconsatz ist zu dem etwas größer bei den Element-Abständen eingestellt, was zwar auf einem Tablet besser sein wird, aber leider bei einem 20 Konten. mit jeweils 40 Unterordnern, Thunderbird nur eine unnötige Platzverschwendung darstellt.

Die Thunderbird-Telemetriedaten

Nicht ganz so erfreulich, aber zum Glück abwählbar, ist die Zwangsaktivierung der Telemetriedaten.

Diverse Nutzer, meine Wenigkeit inklusive, konnten nachweisen, daß die Übermittlung der Telemetriedaten an Thunderbird vor dem Update ausgeschaltet war und automatisch aktiviert wurde. Ihr solltet das also genau prüfen, wenn Ihr jetzt 78.3.1 oder schon 74.x bekommen habt.

Hier könnt Ihr das abschalten:

Wie man sehen kann, war das die Schwarz-Weiße-Phase nach dem Themewechseltest 😀

Die Thunderbird Devs sind dran, auch wenn Sie wenig begeistert waren, daß mehrere Fehler in einem Bugreport gemeldet wurden. Das bringt mich auch gleich zum Abschluß, denn ..

Eine Sache muß ich noch gerade ziehen

Ich hatte heute morgen einen Datenschutzverstoß von Thunderbird gemeldet. Dieser konnte gegen 21 Uhr zu meiner Zufriedenheit von den Thunderbird Devs aufgeklärt werden und ist damit erledigt. Die Datenschutzbeschwerde beim LFD und BFD bereits durch mich zurückgezogen und als erledigt erklärt worden.

Damit Ihr diese Nachricht auch findet, wenn Ihr der alten Artikelurl folgt, wurde dieser Artikel als Ersatz eingestellt. Das ist also der Grund wieso Ihr etwas anderes gesehen habt, als Ihr vielleicht erwartet habt.

 

Nemo: kleines Datenspurenproblem

Moin,

auf der Suche nach einer Erklärung wieso Nemo ständig mit unsortierten Verzeichnislisten startet, statt der eingestellten alphabetischen Reihenfolge, stieß ich auf ein kleines Datenspurenproblem.

Nemo: kleines Datenspurenproblem

Nemo, der Dateiexplorer von Cinnamon, merkt sich die Position jedes Icons auf dem Desktop in einer Datei: ~./config/nemo/desktop-metadata

Wenn man wie ich noch Restbestände aus der Steinzeit des Digitalen Films vorrätig hat, damit man bei Internetausfall, NetFlixpleite oder Implosion von Amazon+ noch Unterhaltung einspielen kann, hat man ein Problem. Auch wenn Ihr häufig Live-Images mountet, USB Sticks benutzt oder sonstige Laufwerke auf Eurem Desktop aufpoppen habt, dann seid auch Ihr von der Nemo-Datenspuren-Panne betroffen.

Jedesmal, wenn ein Laufwerk gemountet wird, erscheint dazu ein Icon auf dem Desktop. Ein Icon auf dem Desktop muß eine Position haben und die muß man als Desktopmanager speichern. Das passiert in obiger Datei.

Am Ende sieht diese Datei dann leider so aus:


[mtp.volume]
nemo-icon-position=91,834
monitor=0
icon-scale=1
nemo-icon-position-timestamp=1499790545

[THE_HOBBIT_AUJ_EXTENDED_PART_2.volume]
nemo-icon-position=221,34
monitor=0
icon-scale=1
nemo-icon-position-timestamp=1507039069

Damit speichert diese Datei leider mehr als genug um interessant zu sein: Name und Datum der Erstsichtung des Mediums. Alleine schon, daß man sehen kann, welchen Film man sich angesehen oder welchen USB Stick man benutzt hat, ist schon erschreckend, aber dazu noch das Datum + Uhrzeit auf die ms genau, ist ein Log das nicht sein sollte.

Das merken des Datums ist für den Zweck außerdem völlig unnötig, außer man würde bei jedem mal, wenn man das Icon benutzt, den Stand aktualisieren und alle die Icons löschen, die seit X Monaten nicht mehr benutzt wurden. Das passiert leider nicht.

Um es Euch einfach zu machen, habe ich da mal was zusammen gebastelt:

$ grep timestamp desktop-metadata | sed -e „s/^.*=//g“ | awk ‚{print „date –date=\“@“$1″\““;}‘ | bash

Für etwas Wissbegierigere:

#!/bin/bash

ALISTE=$(cat $1)

for line in $ALISTE; do

if [[ "$line" == *"volume"* ]]; then
       echo $line;
fi

if [[ "$line" == *"timestamp="* ]]; then
       echo "$line"| sed -e "s/^.*=//g" | awk '{print "date --date=\"@"$1"\"";}' | bash
fi

done

kommt das bei raus u.a.:

[DIE_KAENGURU-CHRONIKEN.volume]
Di 8. Sep 17:11:15 CEST 2020
[Fedora-WS-Live-32-1-6.volume]
Di 29. Sep 17:58:48 CEST 2020
[Fedora-WS-Live-33_B-1-3.volume]
Do 1. Okt 13:04:21 CEST 2020
[Fedora-WS-Live-33_B-1-3.volume.2]
Mi 30. Sep 23:51:27 CEST 2020

[Kommentarspur: Ja ich geb es zu, ich hab ihn gesehen und er war nicht so toll. Ich hatte da mehr auf Jesus,Gott und die DNA Bombe gehofft 😀]

Da Volumen mit Icon auch alles das ist, was man per SSHFS, CUTEFS, FTPMOUNT usw. mountet, verrät diese Datei auch auf welchen Servern man unterwegs war.  Das sind alles META-Daten die nicht sein müßten.

Den Namen des Volumens könnte mit SHA256 hashen, mit einem per-PC-Salt natürlich, das Datum könnte als Löschdatum benutzt werden und so zur Selbstreinigung beitragen. Das sind nur minimale Änderungen, würden die ganze Sache aber komplett entschärfen!

Daher werde ich mich da mal wieder mit Scott rumprügeln müssen, da er dafür Verantwortung zeigt 🙁

Allemal sind diese und andere Dateien Ihres Types, ein Argument für eine pauschale Festplattenvollverschlüsselung beim Setup eines PCs.