FireFox auf Version 55 aktualisieren

In FireFox < 55 klaffen mehrere dicke Sicherheitslücken, daher ist ein sofortiges Update nötig.

Leider stellt Fedora noch keine Updates im Testrepository bereit, so daß man selbst Hand anlegen muß.

Wie üblich muß dazu Koji bemüht werden, denn das entsprechende Firefoxupdate gibt es dort bereits:

firefox-55.0-5.fc25.x86_64.rpm

firefox-55.0-5.fc26.x86_64.rpm

Für Fedora 27 hat der Build nicht geklappt, daher muß man hier noch warten.

Warum hier die Update nicht gepusht werden, obwohl die Lücken gravierend sind, weiß der Geier. Bereits gestern wurden die CERTs darüber informiert und haben die entsprechenden Warnungen an die Listen weitergegeben.

Manpages und die Hilfe

Manpages, die erste Anlaufstelle für Informationen zu allem, was auf einem Linuxsystem an Programmen,Strukturen und weiteren Infos zur Verfügung steht, kennt man eigentlich nur aus der Konsole. Dort werden sie mit dem Befehl „man“ abgerufen.“Man“ ist die Abkürzung für Manual, also Handbuch. Es ist sehr praktisch direkt in der Konsole nach Informationen zu suchen, weil man dazu nicht erst von Rechner weg, seinen Stapel mit Büchern durchsuchen muß und vor allem, weil die „manpages“ aka. Handbuchseiten, jederzeit auf dem aktuellen Stand sind.

Beispiel: „man ls

LS(1) Dienstprogramme für Benutzer LS(1)

BEZEICHNUNG
 ls - Verzeichnisinhalte auflisten

ÜBERSICHT
 ls [OPTION]… [DATEI]…

BESCHREIBUNG
 Auflistung von Informationen über die DATEIen (Standardvorgabe ist das aktuelle Verzeichnis). Die Einträge
 werden alphabetisch sortiert, falls weder -cftuvSUX noch --sort angegeben wurden.

Die obligatorischen Argumente für Optionen sind für deren Kurz- und Langform gleich.

-a, --all
 Einträge nicht ignorieren, die mit ».« beginnen
... usw. ...

Die Ausgabe des „man“ Befehls erfolgt bei direkt in die Konsole, wo man auch nach Begriffen suchen kann. Das es auch anders geht, zeigt folgendes Beispiel. Auf der Suche nach einem Problem vom Systemd kam folgende Ausgabe zustande:

Bild wie Manpages unter Linux verlinkt sind.

Manpagelink in der Konsole

Als weiterführende Dokumentation ist ein Manpage-Link angegeben, den man u.a. über das der Konsole anhaftende Contextmenü mit „Link öffnen“ lesen kann. Statt direkt in der Konsole die Informationen anzuzeigen, öffnet sich die GNOME-Hilfe App:

Manpage in der Hilfeapp

Manpage in der Hilfeapp

Die dort dargestellten Links sind wie in einer Webseite klickbar, aber leider existiert das Ziel nicht immer :

die Verlinkung in der Manpages-Datenbank ist nicht immer vollständig.

Was nicht geht

Trotzdem ist das Handbuch die erste Anlaufstelle, wenn man etwas wissen will. Es lohnt sich eigentlich immer da reinzuschauen. Es kann auch vorkommen, daß die Informationen eine wahre Flutwelle annehmen:

Beispiel: „man systemd.directives“

COLOPHON
 This index contains 2135 entries in 13 sections, referring to 228 individual manual pages.

Ja, das scrollen dauert eine Weile 😉

Nicht immer gibt es eine deutsche Übersetzung für die Informationen, ein bisschen Englisch aus der Schule kann also nicht schaden 🙂  Was es aber scheinbar nicht gibt, sind Witzbolde die Manpages schreiben. Einer kleinen Recherche nach, gibt es keine Hinweise auf lustige oder kuriose Handbuchseiten. Irgendwie schade . Dicht dran, das Ubuntu Handbuch .

Spaß in der Konsole geht aber trotzdem :

cowsay, ein Programm um lustige Hinweise in der Konsole auszugeben

Was die Kuh sagt…

Das kleine Programm heißt „cowsay“ und es gibt es auch für den Desktop. Ob und wo die Kuh zu Dir spricht, bestimmtst aber nicht Du 😉

Jitsi kann keine SIP Anrufe mehr annehmen

Wer kennt das nicht, in der Firma läuft es ruhig. Kunden melden sich nur per Email, aber das Telefon schweigt seit Tagen. Das alljährliche Sommerloch, wegen dessen wir alle in den Urlaub fahren …, oder ?

Paranoide Menschen würden jetzt per Telefon sich selbst anrufen und entsetzt feststellen, daß die Telefone nicht klingeln, weil .. ja .. scheisse, wieso klingeln die nicht ????!!!!!!

Ab jetzt herrscht Panik in der IT-Abteilung:  Was ist passiert ?

Ist der SIP Provider pleite gegangen ?
Haben Mäuse die Glasfaserkabel geknackt ?
Oder liegt es etwa an uns ?
Gab es ein Update der Telefonsoftware ?
Gab es überhaupt irgend ein Update ?

Also prüfen wir zunächst mal, ob alle betroffen sind und stellen fest : Alle Jitsi SIP Softphones sind quasi tod, aber normale Telefone für SIP nicht. Jitsi kann zwar noch raustelefonieren, sonst wäre das ja auch eher aufgefallen, aber ankommende Anrufe gehen nicht mehr. Komischerweise geht Jitsi auf den Handies noch.

Das schliesst per se ein DSL Router und Netzwerkproblem aus, außer die lokale Firewall wäre im Spiel:

TEST:
systemctl stop firewalld
Anruf => kein Klingeln
systemctl start firewalld

Das wars nicht. Hatte Jitsi ein Update ? Seit Monaten nicht mehr.  Fällt somit als Ursache auch weg.  Hmm…

2 Tage und eine systematische Suche später ..

Das Problem, das  Jitsi keine SIP Calls mehr annehmen konnte, ist behoben worden.

Es lag NICHT an Jitsi, Sipgate, den Mäusen, dem DSL Router, den Kabeln, der Firewall sondern an :  JAVA.

Die Ursache

Fedora hat vor zwei Tagen ein neues openjdk 1.8.0.141_b16 eingespielt, das hat Jitsi und vermutlich andere Apps beeinträchtigt. Das Update war als Security Update markiert, es ist also potentiell gefährlich, die App weiter zu betreiben. Ist es in dem Fall nicht, da das Update pauschal als Security Update eingestuft wurde, weil 4 Security Tests beim Build nicht liefen. Dazu noch eine Menge normaler Updates, von denen vermutlich eins die Ursache ist.

Der Workaround

Der schnellste Workaround ist natürlich, Java zu downgraden auf die letzte funktionierende Version:

java-1.8.0-openjdk-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-devel-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-headless-1.8.0.131-5.b12.fc25.x86_64.rpm
java-1.8.0-openjdk-javadoc-1.8.0.131-5.b12.fc25.noarch.rpm

Wenn man das jetzt mit „dnf downgrade java-*“ macht, landet man bei einer uralten Version, was Securitymäßig keine gute Idee ist. Also lädt man die Pakete hier runter:

https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/noarch/java-1.8.0-openjdk-javadoc-1.8.0.131-5.b12.fc25.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-headless-1.8.0.131-5.b12.fc25.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-devel-1.8.0.131-5.b12.fc25.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/java-1.8.0-openjdk/1.8.0.131/5.b12.fc25/x86_64/java-1.8.0-openjdk-1.8.0.131-5.b12.fc25.x86_64.rpm

Aber natürlich nur passenderweise für Fedora 25, andere Versionen bitte selbst bei koji suchen.

Nicht vergessen: /etc/dnf/dnf.conf editieren und java auf die Sperrliste setzen, sonst kommt das Update gleich wieder rein.

Warum ist jetzt der Downgrade auf b12 akzeptable und der auf die Fedora Downgrade Version nicht ?

Weil Jitsi nur Verbindungen zu bestimmten, vertrauenswürdigen Servern aufnimmt. Es ist daher kaum möglich etwaige SecBugs in Java über diesen Channel auszunutzen, zumal in der ML von OpenJAVA keine Hinweise zu Securitybugs enthalten waren. 4 Tests beim Build failten, das kann alles sein. in nächster Zeit wird es sicher Updates von Jitsi geben, damit es auch mit der aktuellen Java Version läuft, denn es steht zu befürchten, daß Openjdk, den „Bug“ nicht fixt.