Linux: Mehr Tester für Fedora!

Das Wort zum Sonntag

„Moin, Moin liebes Fedoravolk,

Schämt Euch! Ja…schämt Euch in Grund und Boden!
Ihr wollt alles immer für lau, aber so läuft das nicht!
Eure Taten sollen für Euch die Rechnung bezahlen,
deswegen TESTET! TESTET! TESTET! “
(Zitat: von Manager Bodhi, 20-20 )

So, oder so ähnlich, hätte das wohl geklungen, wenn Linux eine Religion wäre und der örtliche Glaubensvertreter Euch in den Allerwertesten treten wollte. Glück für Euch, Linux ist keine Religion. Nichts desto trotz, könntet Ihr ruhig mehr für Euch selbst tun und öfters mal zumindest bei sicherheitskritischen Sachen neue Updates testen!

Das Firefox 73.0-2 Update für Fedora 30 hing bis heute morgen 9.35 Uhr immer noch im Testbereich rum, wohingegen das gleiche Paket für F31 schon nach Minuten genug Testergebnisse zusammen hatte und bereits ins Stable gerutscht ist.

Koji and Bodhi in a Nutshell

Damit sich mehr Benutzer finden, die Tests mit Auswirkungen machen, sei am Beispiel von Firefox erklärt, wie man da als normaler Benutzer helfen kann:

Das ist der Testfall für Firefox 73.0-2 für Fedora 30 im BODHI System:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-4e1ba1a692

Wenn man die Seite aufruft, sieht man als erstes die Installationsanleitung:

Man sieht eine Testfallliste im Bodhi interfaceDie spannende Frage ist jetzt natürlich, wie kommt man überhaupt an den Links zu den Updates ran?

Dazu ruft man die Webseite ohne irgendetwas auf, z.b. so:

https://bodhi.fedoraproject.org/updates/

Ihr findet eine Suchmaske rechts oben:

Man sieht eine Liste mit Updates, welche genau, ist für das Thema komplett egal.Einfach „Firefox“ eingeben oder durch die Liste scrollen(aber das dauert etwas).

Updates sind intern eingeteilt in normale Programme und welche, die zum CritPath, also den kritischen Programmen, zählen. Firefox als „der“ Browser ist ein CritPath Programm, das Genologie Programm dagegen, ist nicht kritisch für den täglichen Betrieb beim Enduser, also ein normales Programm.

Testfälle

Entsprechend gibt es diverse Testfälle, die für solche Updates neben dem obligatorischen „Es startet überhaupt“ gibt. Für Firefox wären das diese drei:

Amn sieht einen ordentlich gemachten Test eines Testers von FirefoxEs gibt bei anderen Programmen auch welche mit deutlich mehr Testfällen. Der Maintainer kann auch spezielle Testfälle hinzufügen, wenn bestimmte Neuerungen das erfordern sollten um die Kompatibilität mit dem bisherigen Datenbestand zu sichern.

Die drei Fälle hier sind also „Addons: funktioniert die Addonseite, sind alle Addons da, kann man welche installieren“, „Browser: Kann man damit Webseiten aufrufen, gibts Probleme bei der Darstellung usw.“ und „Media: kann man Filme, Musik, Bilder ansehen und anhören.“

Wie man oben sehen kann, hat der Tester für alle drei grünes Licht gegeben, aber einiges anzumerken gehabt. Offensichtlich hat er den Test ernster genommen als Andere, die diese Testfälle nicht geprüft haben. Wenn man hier Tests macht, sollte man auf keinen Fall Testergebnisse fälschen, das bringt rein gar nichts, für niemanden.

Insgesamt sind min. 3 positive „Karma+1“ Wertungen nötig um ein Update als lauffähig zu markieren. Schauen wir uns mal an, wie die anderen Tester gewertet haben:

Das "Testergebnis" anderen Menschen, leider nicht ganz so penibel wie im vorherigen Fall. Nur einer der zwei Anderen hat den Browsertest gemacht und gewertet, daß er funktioniert ( der Firefox ). Die anderen Tests haben sich die zwei einfach erspart. Rechts oben auf dem Bild seht Ihr noch die automatisch durchgeführten Funktionstests und da hat das Update 3 nicht bestanden. Jetzt darf der Maintainer entscheiden, ob das missionskritische Fehler sind oder nur formale Fehler, und diese dann überstimmen.

Die Auswertung

Wenn keine automatischen Fehlerergebnisse vorliegen und das Karma +3 erreicht hat, wird dem Maintainer geraten und erlaubt, das Update ins Stable zu schieben. Das kann in Notfällen auch überstimmt werden durch den Maintainer, wenn z.b. die Hütte schon brennt, sollte man das Feuerwehrauto vielleicht nicht erst noch testen, sondern nur zusehen, daß Wasser im Tank ist. Das Äquivalent bei Software ist ein Remote-Exploit, der in der Wildnis (Internet) bereits zu der Lücke kursiert und PCs infiziert. Da ist es natürlich besser, wenn das aktualisierte Programm gar nicht mehr geht, statt die Leute weiter der Gefahr auszusetzen gehackt zu werden.

Ihr könnt mir glauben, wenn ich Euch sage, daß sich da keiner eine leichte Entscheidung macht. Desöfteren brauchte es massives Schubsen, daß Updates ins Stable gepusht wurden, um schlimmeres zu verhindern.

Karma +3

Ihr habt jetzt gelernt, daß es nur 3 positiver Tests bedarf um ein Update an die User raus zuschicken ( Umschreibung für „ins Stable schieben“ ).

Es hat bei FF73 für F30 satte 2 Tage gebraucht, bis 3 Leute einen Test gemacht hatten. Wenn man bedenkt, daß es sich um ein kritisches Sicherheitsproblem in Firefox gehandelt hat, ist das eher armseelig(für die Menschheit). 3 Menschen von 8.000.000.000 oder auch 0,000000037% der Menschheit.

Dafür das Fedora in den Jahren 2016-2018 4 Millionen Abrufe von Updates pro Monat hatte, Spiegelserver bei Unis nicht miteinbezogen, sollte man doch annehmen, daß es ein paar mehr Benutzer gibt, die da mal 3 Minuten für einen Test übrig haben, besonders, wenn es um Ihre persönliche Sicherheit geht, oder?

Wie wird man jetzt überhaupt Tester?

Jetzt der Teil, der für Mensch Nr. 4 aufwärts gedacht ist, die Antwort auf die Frage, wie man denn Tester werden kann. Ihr braucht: das passende OS für Euren Test ( Fedora 30/31 ) und ein Emailprogramm.

Die Emailaddresse braucht es zum Anmelden bei Fedora, denn Tester bekommen auch Emails mit Updates zu dem, was sie da testen ins Haus. Das ist schon daher wichtig, weil man so sieht, ob man etwas vergessen hat zu testen. Sollte einem da ein Fehler unterlaufen sein, kann man sein Testergebnis auch nachbessern, selbst wenn das Update dann zurückgezogen wird:  Karma < -2 .

Wenn man sich hier angemeldet hat:

Die Loginmaske vom FAS System zu Anmelden, nichts spannendes, wenn man es nicht sehen kann.kann man schon loslegen. „Sign up now“ ist der Knopf für Euch, wenn Ihr noch keinen Login zum Fedora Authentication System „FAS“ habt. Mit so einem FAS Login kann man auch bei ASKFEDORA mitmachen, also der Plattform, die Fragen von Benutzern an Benutzer unterstützt. Und das wars schon. Mehr Aufwand ist nicht nötig um zu helfen.

Und was ist jetzt Koji?

Das ist i.d.R. meine Quelle, wenn ich wissen will, ob da schon eine Testversion unterwegs ist, oder nicht. Selbst wenn die Testversion den Test nicht bestanden hat oder aus anderen Gründen zurückgestellt wurde, kann man dort alle bekannten Versionen finden und downloaden.

Koji findet Ihr unter dieser Adresse: https://koji.fedoraproject.org/

Für Firefox sieht das derzeit so aus:

Eine Liste mit Updates von Fedora zu Firefox in verschiedenen Stadien und Versionen. Wer die Seite mit einem Screenreader aufsucht, kann am Namen der Updates genau erkennen um welche Version es sich handelt.Wie man leicht erkennen kann, kommt das selbst bei renommierten Programmen vor, das man die nicht gebaut bekommt ( rot ). Jeden der Builds oben könnt Ihr dort passend für Euren PC ( OS+Architektur) runterladen.

Da kann man z.b. auch so Sachen machen, wie „mit FF 69 liefs noch, aber ich habe meine Daten nicht exportiert vor dem Update“ schon zieht man sich die alte Version, installiert diese, macht noch alle nötigen Anpassungen an seinen Daten zum Export und updated dann wieder auf die aktuelle Version hoch.

Auf welchem anderen OS kann man das schon machen? 😉

Firefox 73.0 für FC30 und FC31 verfügbar

Es ist mal wieder soweit, eine Sicherheitslücke in Firefox und Thunderbird ( da nicht dramatisch mangels Scripting ) zwingt Euch zu einem Update. Ja, „Euch“, weil ich habe schon 😉

Firefox <73.0 mit Sicherheitslücken

Memory Corruption, Sicherheitslücke, wenn Firefox PDF Reader spielt(ARGS!) und eine RCE Schwachstelle, bei der ein Angreifer Code in Firefox ausführen kann ( und nicht nur in der Webseite im Firefox 😉 ) sind nur einige der Löcher die damit gestopft werden. Kleine Liste:

Mozilla Foundation Security Advisory 2020-05
Security Vulnerabilities fixed in Firefox 73

Announced February 11, 2020
Impact high
Products Firefox
Fixed in Firefox 73

#CVE-2020-6796: Missing bounds check on shared memory read in the parent process

A content process could have modified shared memory relating to crash reporting information, crash itself, and cause an out-of-bound write. This could have caused memory corruption and a potentially exploitable crash.
References

#CVE-2020-6797: Extensions granted downloads.open permission could open arbitrary applications on Mac OSX

By downloading a file with the .fileloc extension, a semi-privileged extension could launch an arbitrary application on the user’s computer. The attacker is restricted as they are unable to download non-quarantined files or supply command line arguments to the application, limiting the impact.
Note: this issue only occurs on Mac OSX. Other operating systems are unaffected.
References

#CVE-2020-6798: Incorrect parsing of template tag could result in JavaScript injection

If a <template> tag was used in a <select%gt; tag, the parser could be confused and allow JavaScript parsing and execution when it should not be allowed. A site that relied on the browser behaving correctly could suffer a cross-site scripting vulnerability as a result.
References

#CVE-2020-6799: Arbitrary code execution when opening pdf links from other applications, when Firefox is configured as default pdf reader

Command line arguments could have been injected during Firefox invocation as a shell handler for certain unsupported file types. This required Firefox to be configured as the default handler for a given file type and for a file downloaded to be opened in a third party application that insufficiently sanitized URL data. In that situation, clicking a link in the third party application could have been used to retrieve and execute files whose location was supplied through command line arguments.
Note: This issue only affects Windows operating systems and when Firefox is configured as the default handler for non-default filetypes. Other operating systems are unaffected.
References

#CVE-2020-6800: Memory safety bugs fixed in Firefox 73 and Firefox ESR 68.5

Mozilla developers and community members Raul Gurzau, Tyson Smith, Bob Clary, Liz Henry, and Christian Holler reported memory safety bugs present in Firefox 72 and Firefox ESR 68.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code.
References

# Memory safety bugs fixed in Firefox 73 and Firefox ESR 68.5

Wenn Ihr Euch die Update holen wollt, bevor die automatisch kommen, hier kann man Sie passend runterladen:

FC30: https://koji.fedoraproject.org/koji/buildinfo?buildID=1459513

FC31: https://koji.fedoraproject.org/koji/buildinfo?buildID=1459512

 

Fedora Koji ist wieder da..

Diesmal nur die Kurzfassung, der Ausfall bei Fedora ist soweit behoben, Koji ist auch schneller als sonst und der Fehler ist auch bereits bekannt: ein Level 8 Problem.

Ursache war ein Fix für einen anderen Fehler, der kurzerhand alles zerlegt hat. Da muß man jetzt zwangsweise eine Parallele zu diesem Beitrag ziehen: Kernel 5.3.16 mit HDMI-Audio Problemen Wobei das nicht die gleichen Leute waren 😉

Fedora Koji ist derzeit offline

Das Fedora Buildsystem Koji ist derzeit außer Betrieb aka. Offline. Da es dazu keine Ankündigung gab, kann man nur von einem Ausfall sprechen. Da hiervon aber auch alle Downloads aus dem Buildbereich betroffen sind, kann man derzeit nichts recherchieren oder ausprobieren. Dies bedeutet auch, daß alle Koji Links aus diesem Blog derzeit offline sind.

Fehlermeldung Server ist offlineSeit einigen Tagen Probleme

In der Entwickler Mailingliste wurden schon seit einigen Tagen dubiose Fehlermeldungen und lange Prozesslaufzeiten gemeldet. Ein Neustart des System brachte wohl nur kurzfristig Entlastung. Ein Zusammenhang mit dem derzeit laufenden 36C3 kann man wohl ausschließen, da Kevin Fenzi schon vor 7 Tagen darüber berichtet hat:

Aufgrund der Fehlermeldungen bricht da derzeit vermutlich ein Datenbankserver(Cluster) in sich zusammen, der für die Buildumgebung da ist.
Ich halte Euch auf dem laufenden.

selinux-policies auf den letzten funktionierenden Stand bringen

Wie Ihr ( und .tux. )  im letzten Bericht zu selinux-policy lesen konntet, wurde das SEL Problem mit einem generellen Downgrade erstmal behoben. Heute schauen wir uns an, wie man das trotz aller Gegenwehr von Red Hat wieder auf den letzten aktuellen Stand geupdated bekommt 😉

Fedora und die Repostrukturen

Wenn man dnf downgrade benutzt, bekommt man nicht automatisch die letzte Version von einem Paket installiert, sondern nur die nächst kleinste im Repository (Repo) und genau da happerts meiner Meinung nach bei Fedora und Red Hat. Man sollte ja annehmen, daß die aktuelle Version und die vorherige Version eines Paketes zur Verfügung stehen, tun Sie aber nicht. Fedora betreibt ein Basis Repo und ein Updates Repo. Eine funktionierende alte Fassung liegt im Basis Repo, die aktuellste im Updates Repo. Zwischenversionen gibt es leider keine und das ist, denke ich, ein Fehler von Seiten der Distribution.

Immer wieder Koji

Und wieder ist es Koji, die Buildverwaltung für Fedora, die uns bei der Sache als nützliche Datenquelle dient:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1076199

Dort holen wir uns die nötigen RPMs für die lokale Installation:

https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-targeted-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-devel-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-doc-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-3.13.1-283.34.fc27.noarch.rpm

Wer meiner Anweisung gefolgt ist, und in die dnf.conf eine Sperre für das Paket eingetragen hat, muß diese Sperre jetzt natürlich wieder entfernen, bevor er das Update durchführen kann.

Manuelles DNF Update

Der Befehl „dnf update ./selinux-policy-*“ ist unser Freund:

[root]# dnf update ./selinux-policy-*
Letzte Prüfung auf abgelaufene Metadaten: vor 0:24:25 am Di 10 Jul 2018 09:59:33 CEST.
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Aktualisieren:
selinux-policy noarch 3.13.1-283.34.fc27 @commandline 541 k
selinux-policy-devel noarch 3.13.1-283.34.fc27 @commandline 1.4 M
selinux-policy-doc noarch 3.13.1-283.34.fc27 @commandline 2.7 M
selinux-policy-targeted noarch 3.13.1-283.34.fc27 @commandline 10 M

Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Aktualisieren 4 Pakete

Gesamtgröße: 15 M
Ist dies in Ordnung? [j/N]:j
Pakete werden heruntergeladen:
Transaktionsüberprüfung wird ausgeführt
Transaktionsprüfung war erfolgreich.
Transaktion wird getestet
Transaktionstest war erfolgreich.
Transaktion wird ausgeführt
Vorbereitung läuft : 1/1 
Aktualisieren : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Aktualisieren : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Ausgeführtes Scriptlet: selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Aufräumen : selinux-policy-devel-3.13.1-283.14.fc27.noarch 5/8 
Aufräumen : selinux-policy-doc-3.13.1-283.14.fc27.noarch 6/8 
Aufräumen : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Aufräumen : selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Running as unit: run-ra699effd01cd4ceba2ad927e7889ce3b.service
Running as unit: run-r27b6453c4a5e4d2ab971a1766a434a30.service
Überprüfung läuft : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 5/8 
Überprüfung läuft : selinux-policy-3.13.1-283.14.fc27.noarch 6/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.14.fc27.noarch 7/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.14.fc27.noarch 8/8

Aktualisiert:
selinux-policy.noarch 3.13.1-283.34.fc27 selinux-policy-devel.noarch 3.13.1-283.34.fc27 selinux-policy-doc.noarch 3.13.1-283.34.fc27 selinux-policy-targeted.noarch 3.13.1-283.34.fc27

Fertig.

Nicht vergessen die dnf.conf wieder mit einer Sperre zu versehen :

# cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
exclude=selinux-pol*

Damit wären wir jetzt auf dem Stand, vor dem defekten Paket und bekommen erstmal keine Updates mehr für die selinux-policies.

Ob das so clever war, die automatischen Tests zu umgehen?

Wenn ich der Darstellung im Buildsystem glauben darf, dann wurde für den Push Tests umgangen. Da es nachweislich in die Hose gegangen ist, ist das wohl keine gute Idee.

Wissen eigentlich alle was diese Policies so machen ?

mit dem Befehl „rpm -qi selinux-policy“ bekommen wir eine Beschreibung des Pakets. Leider ist die in diesem Fall äußerst schmal geraten:

„SELinux Base package for SELinux Reference Policy – modular.
Based off of reference policy: Checked out revision 2.20091117“

Daher schauen wir doch mal in ein solches Paket rein. Jetzt ist selinux-policy kein sehr nützliches Beispiel, es setzt nämlich lediglich die System-Konfiguration und andere Metainfos. Viel spannender ist das selinux-policy-targeted Paket, daß die eigentlichen Regeln enthält. U.a. finden wir dies File darin:

/usr/share/selinux/targeted/default/active/modules/100/gnome/cil

Wenn man sich das jetzt mit less ansieht, sieht man nichts, da es bzip2 komprimiert ist. Daher brauchen wir jetzt das hier:

bzless /usr/share/selinux/targeted/default/active/modules/100/gnome/cil

u.A. findet man dann dort die Beschreibungen welche Dateien welche SEL-Contexte haben sollen:

(Die Liste ist nicht vollständig und nur für die eine Gnome Klasse)

(filecon „/var/run/user/[^/]*/\.orc(/.*)?“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/dconf(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/keyring.*“ any (system_u object_r gkeyringd_tmp_t ((s0) (s0))))
(filecon „/root/\.cache(/.*)?“ any (system_u object_r cache_home_t ((s0) (s0))))
(filecon „/root/\.color/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.config(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.kde(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.gconf(d)?(/.*)?“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.dbus(/.*)?“ any (system_u object_r dbus_home_t ((s0) (s0))))
(filecon „/root/\.gnome2(/.*)?“ any (system_u object_r gnome_home_t ((s0) (s0))))
(filecon „/root/\.gnome2/keyrings(/.*)?“ any (system_u object_r gkeyringd_gnome_home_t ((s0) (s0))))
(filecon „/root/\.gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.cache/gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.local.*“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.local/share(/.*)?“ any (system_u object_r data_home_t ((s0) (s0))))
(filecon „/root/\.local/share/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.Xdefaults“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.xine(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/etc/gconf(/.*)?“ any (system_u object_r gconf_etc_t ((s0) (s0))))
(filecon „/tmp/gconfd-USER/.*“ file (system_u object_r gconf_tmp_t ((s0) (s0))))
(filecon „/usr/share/config(/.*)?“ any (system_u object_r config_usr_t ((s0) (s0))))
(filecon „/usr/bin/gnome-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/bin/mate-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gconf-defaults-mechanism“ file (system_u object_r gconfdefaultsm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gnome-system-monitor-mechanism“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/kde(3|4)/ksysguardprocesslist_helper“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))

und in der findet sich dann kein Hinweis auf den gdm-greeter oder die gnome-session .. Womit es undefiniert ist.

Ich hab versucht da  durchzusteigen, aber das ist echt komplex das Zeugs 😉 Vielleicht will ja mal einer ein Diagnosetool dafür bauen, da berichte ich dann gerne drüber.