Category Archives: Fedora

Red Hat Politikänderungen wirken auch auf Fedora nach

Posted on by

Red Hat hatte ja einige Änderungen am Engagement für Desktopelemente in Aussicht gestellt, die jetzt langsam durchschlagen.

Red Hat Politikänderungen wirken auch auf Fedora nach

Bastien Nocera schreibt in seinem Blog, daß er von Red Hat in ein anderes Team versetzt wurde und die ohnehin schon geringe Arbeit an „fprint, fprintd, gnome, gvfs, iio-sensor-proxy, kernel, libfprint, low-memory-monitor, power-profiles-daemon, rhythmbox, sound-juicer, switcheroo-control, thumbnailer, totem“ einstellen mußte. Das führte zum Verwaisung der Pakete bei Fedora.

Langzeit Maintainer Michael Catanzaro, der auch bei Red Hat angestellt ist, schrieb dazu am Montag auf der Fedora Dev ML:

„Red Hat has instructed us to stop work on several core desktop components. All of these components need new maintainers now. The switcheroo-control repo has now been archived, and a future new maintainer will need to recreate the repo in a new location. It’s certainly not good news. :(„

Cinnamon & Nvidia Maintainer Leigh Scott nahm das zum Anlass um wenigsten einige der Pakete von der LinuxMint Gruppe übernehmen zu lassen. Dutzende andere Pakete warten aber noch auf einen neuen Maintainer.

Der ‚Umorientierung‘ bei Red Hat, der mutmaßlich von IBM inszeniert wurde, geht also weiter und wird sicherlich noch spürbare Ausmaße annehmen, weil Red Hats Engagement weitest gehend im  Stillen abgelaufen ist. Das wird sich sicherlich jetzt ändern.

Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Posted on by

Vor einigen Tagen hatte ich ja was zum Kernel Bug geschrieben, nämlich, daß ich mir mehr Sorgen mache, daß eins der Desktopprogramme geknackt wird. Jetzt ist es bei Ghostscript soweit.

Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Ghostscript < 10.1.02  hat eine Schwachstelle, die das Ausführen von Code erlaubt. Das an sich ist schon schlimm, wenn man dann erfährt, daß das bei den Maintainer untergegangen ist 🙁

Schlimmer ist aber, daß die Lücke in andere Anwendungen wie InkScape, LibreOffice und Gimp eskaliert, dort also auch funktioniert. Möglich macht dies das Äquivalent der größten Container-Sorge überhaupt: Diese Anwendungen halten sich eine selbst gepatchte Version von Ghostscript in der Codebasis und naja, in der ist der Bug auch drin.

Das ist vergleichbar mit einer Sammlung von Docker Containern,Snaps & Flatpaks, welche alle die gleiche ausnutzbare libPNG drin haben und jetzt alle geupdated werden müssen, wo ja eigentlich nur eine Komponente das Update wirklich bräuchte: Ghostscript. Was zeigt das: Dumme Entscheidungen brauchen kein Containermodell 😉

Anstatt einer Komponente, müssen jetzt ein Haufen unübersehbarer Anwendungen aktualisiert werden, wozu man erstmal rausfinden muß, wo das überall drin ist. Das muß man erst mal schaffen. Log4J lässt so derbe grüßen, daß heute wohl Murmeltiertag ist.

Da zu allem Überfluss ein POC-Exploit bekannt ist, werden echte Exploits nicht lange auf sich warten lassen.

Die Situation auf Debian ist besser als die von Fedora, weil Debian immerhin das erste GS Update ausgeschickt hat, bei Fedora aber nichts am Horizont ist. Dagegen habe ich mal was gemailt…

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36664

https://www.kroll.com/en/insights/publications/cyber/ghostscript-cve-2023-36664-remote-code-execution-vulnerability

 

Fedora + Intel: Firefox startet nicht mehr

Posted on by

Fehlerbild: Firefox startet nicht mehr, es kommt nur noch die Meldung „eine andere Instanz von FF würde schon laufen“
Ein „killall -9 firefox“ mit anschließendem Start von Firefox führt nur wieder zum Fehler.

Fedora + Intel: Firefox startet nicht mehr

Das Problem war heute morgen, daß Firefox nicht mehr gestartet ist. kill -9 brachte nichts, und in der Konsole ausgeführt kam dann an einigem Warten die Meldung, daß die VAAP Tests gefailt sind.

Wer eine Intel GPU hat und heute ein Kernel-Update bekommen hat, sollte daher mal checken ob VAAPI noch geht : vainfo

Das muß in etwa so aussehen:

$ vainfo
Trying display: wayland
Trying display: x11
Trying display: drm
libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_15
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake – 2.4.1
vainfo: Supported profile and entrypoints

Wenn das nicht der Fall ist, dann fehlen Euch vermutlich die GPU-Treiber für Intel. Das ist leicht zu überprüfen, in demIhr mal „/usr/lib64/dri/“ auflistet. Falls die oben zu sehenden Treiber nicht da sind, die gibt es bei RPMFusion als RPM: libva-intel-driver

Mit dem Paket geht dann auch Firefox wieder … aber erst nachdem der Firefox einmal im SAFE-MODE ( firefox –safe-mode) gestartet wurde.Es kann sich also auch gut um ein simples Verschlucken von Firefox gehandelt haben. Im schlimmsten Fall habt Ihr jetzt am Ende für Intel hardwarebeschleunigtes Video im Firefox 😉