Cinnamon – Das fehlende Icon

Problem:

Nach dem Update auf Fedora 26 zeigte die Schnellstartleiste ein leeres Iconfeld:

Schnellstartleiste ohne Icon

Schnell stellte sich heraus, daß es sich dabei um die NVIDIA-Settings handelte. Beim eingestellten ICON-Theme gnome :

Themeeinstellungen mit Gnome

 

gibt es nun aber gar kein Icon dafür, weswegen der Platz leer bleibt.

Alle Versuche, das durch direktes Zuweisen in der Desktop Datei unter /usr/share/applications  zubeheben, schlugen fehl.
Die Desktopdatei wurde immer wieder auf die Defaulteinstellungen „Icon=nvidia-settings“  zurückgesetzt.

Da wird wohl rohe Kraft nötig sein, um das System vom Gegenteil zu überzeugen! 😀

Die Lösung

Das läßt sich schnell beheben, wenn man einen Theme hat, so wie MINT-Y, der ein Icon dafür bereitstellt :

cp /usr/share/icons/Mint-Y/apps/256/nvidia-* /usr/share/icons/gnome/256×256/apps/

Dann noch schnell das Theme Cache erstellen :

gtk-update-icon-cache –force /usr/share/icons/gnome/

Ab sofort ist da wieder ein Icon, wo es hingehört. Dies muß man als Rootuser machen :

Iconleiste mit Icon drin

 

 

 

 

 

 

Thunderbird – Ausführen beliebigen Programmcodes

Thunderbird About infos 52.5.0
Alle Thunderbird Versionen vor 52.5.0 sind von einer Remote-Code-Execution (RCE) Schwachstelle und anderen Sicherheitslücken betroffen, die als schwerwiegend eingestuft wurden.

Alarmstatus

Fedorabenutzern stehen derzeit (Stand: 28.11. 14:19 Uhr) KEINE Updates zur Verfügung.

Wie uns Jan Horak von RedHat mitteilt, befindet sich Thunderbird 52.5.0 derzeit im Bau. Testversionen werden daher vermutlich heute noch für Fedora bereitstehen.

Update

Seit 14:55 Uhr stehen die Updates für Fedora zum Download in Koji bereit.

Die frischen RPMs könnt Ihr dann für Eure jeweilige Fedoraversion hier finden :

Fedora 25 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005614
Fedora 26 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005616
Fedora 27 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005615
Fedora 28 : https://koji.fedoraproject.org/koji/buildinfo?buildID=1005618

CERT Warnung zu Thunderbird

Die Warnung des Bund-CERT finden Sie hier : https://www.cert-bund.de/advisoryshort/CB-K17-2035

Thunderbirds Mitteilung

Mozilla stuft die Sache schon etwas genauer ein und dafür, das es bereits am 23. November 2017 gemeldet wurde, haben unsere Distributionen echt langsam gearbeitet, alle, auch Suse .

Wer sich ein Bild machen will, hier die nötigen Infos:

Impact: critical
Products: Thunderbird
Fixed in Thunderbird 52.5

„In general, these flaws cannot be exploited through email in the Thunderbird product because scripting is disabled when reading mail, but are potentially risks in browser or browser-like contexts.“

CVE-2017-7828: Use-after-free of PressShell while restyling layout

„A use-after-free vulnerability can occur when flushing and resizing layout because the PressShell object has been freed while still in use. This results in a potentially exploitable crash during these operations.“

CVE-2017-7830: Cross-origin URL information leak through Resource Timing API

„The Resource Timing API incorrectly revealed navigations in cross-origin iframes. This is a same-origin policy violation and could allow for data theft of URLs loaded by users.“

CVE-2017-7826: Memory safety bugs fixed in Firefox 57, Firefox ESR 52.5, and Thunderbird 52.5

„Mozilla developers and community members reported memory safety bugs present in Firefox 56, Firefox ESR 52.4, and Thunderbird 52.4. Some of these bugs showed evidence of memory corruption and we presume that with enough effort that some of these could be exploited to run arbitrary code.“

Glückwünsche

Wie unsere Quellen berichten, stellt OpenSUSE bereits eine gepatchte Version für SUSE Linux Enterprise 12 sowie OpenSUSE Leap 42.2 und 42.3 bereit.

Glückwünsche an SUSE, Ihr wart die ersten 🙂

 

gleiche RPMs aus verschiedenen Quellen

Ein bisschen speziell ist unser heutiger Fall von Systemupgrade. Wir haben mehrere Repositories/Quellen von RPM Paketen für ein Paket, wollen aber das System per DNF upgraden und ein Paket aus einem bestimmten Repo benutzen.

Das Problem

Wir haben Fedora 25 als OS mit dem Default PHP von Fedora und zwei anderen PHP Versionen von Remi, einem französischen Repository für Serversoftware. Ein Serverupgrade kann man leicht mit

dnf –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

durchführen. Damit alle zusätzlichen Rpms von Drittrepos auch mitkommen beim Update, muß das jeweilige Repo global aktiviert sein, oder man gibt es in der Zeile mit an :

dnf –enablerepo=remi –allowerasing –releasever=26 –setopt=deltarpm=false distro-sync

Wenn man das in unserer Ausgangssituation tut, bekommt man einen Quellwechsel ins Spiel, denn man nicht unbedingt haben will. Remi hat nämlich eine neuere Version von PHP als das Fedorarepo.

Der Unterschied

Das hat natürlich einen Grund, Remi hat sich genau dem gewidmet, neigt aber dazu ohne umfangreiche Testrepos zuarbeiten. Fedora dagegen hat eine Communitytestumgebung, auf der Tester die Pakete bewerten müssen, bevor Sie ins Stablerepo gepusht werden.

Fedora hat also ggf. die stabiler laufenden Pakete, weil überhaupt jemand mal testhalber so ein Paket installiert hat. Auf einer Serverumgebung wollen wir natürlich genau dies haben, außerdem könnten die Remi Pakete anders kompiliert sein, und daher unerwartete Nebenwirkungen haben, was strikt zu vermeiden ist.

Quellrepowechsel verhindern

Gibt man jetzt das Upgradekommando ein und hat alle Quellrepos aktiviert, sieht Dnf das „neuere“ PHP Paket bei Remi und wechselt die Quelle, genauso, also wenn man das Testrepository aktiviert und dort ein neueres Paket vorhanden ist.

Daher muß man das Remirepo deaktivieren und erstmal normal upgraden. Nach dem Reboot kann man dann einfach dnf update benutzen um die Pakete zu aktualisieren, die im Remirepo vorhanden sind.

Überraschung

Bei unserem Beispiel F25 zu F26 und PHP kommt es zu einem Versionssprung von PHP 7 auf PHP 7.1 . Damit haben wir jetzt ggf. zweimal 7.1. drauf, einmal von Fedora und einmal von Remi, wo man doch eigentlich 7.0 und 7.1. haben wollte.

Also lösen wir das auf, indem wir 7.1 von Remi entfernen und 7.0 aufspielen:

dnf –enablerepo=remi update php56* php72*
dnf –enablerepo=remi erase php71*
dnf –enablerepo=remi install -y php70-php-process php70-php-cli php70-runtime php70-php-imap php70-php-common php70 php70-php-pdo php70-php-mbstring php70-php-json php70-php-pear php70-php-gd php70-php-mcrypt php70-php-mysqlnd php70-php-xml

Glückwunsch. Sie haben jetzt vier PHP Versionen auf Ihrem Server 😀

Mit FedUP, dem eigentlichen Upgradetool, hätte man das so nicht geschafft, da wäre das PHP dann auch von Remi gekommen.