Fedora 30: Firefox 72.0.1 im Koji bereit

Aufgrund mehrerer schwerer Sicherheitslücken in Firefox und dem Umstand, daß die Version 72.0 nicht funktioniert hat, gibt es für Fedora jetzt auch die 72.0.1 im Koji zum Download

schwere Sicherheitslücken in Firefox < 72.0

Es ist recht ungewöhnlich, gleich nach einer Security Release wie Firefox 72, noch eine Lücke zu fixen, aber hey, es muß wichtig gewesen sein und hier ist sie:

Security Vulnerabilities fixed in Firefox 72.0.1 and Firefox ESR 68.4.1

Announced      January 8, 2020
Impact critical
Fixed in Firefox 72.0.1 , Firefox ESR 68.4.1

#CVE-2019-17026: IonMonkey type confusion with StoreElementHole and FallibleStoreElement

Description

Incorrect alias information in IonMonkey JIT compiler for setting array elements could lead to a type confusion. We are aware of targeted attacks in the wild abusing this flaw.

Den wichtigen Teil, habe ich Euch mal farblich hervorgehoben 😉 Zusammen mit dieser Lücke:

#CVE-2019-17025: Memory safety bugs fixed in Firefox 72

Reporter Mozilla developers
Impact high
Description

Mozilla developers Karl Tomlinson, Jason Kratzer, Tyson Smith, Jon Coppeard, and Christian Holler reported memory safety bugs present in Firefox 71. 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.

ein Grund mehr sofort zu updaten!

Hier könnt Ihr die aktuelle Version für Euch passend herunterladen, da der Stablepush noch nicht durchgeführt wurde:

F30x32: https://kojipkgs.fedoraproject.org//packages/firefox/72.0.1/1.fc30/i686/firefox-72.0.1-1.fc30.i686.rpm

F30x64: https://kojipkgs.fedoraproject.org//packages/firefox/72.0.1/1.fc30/x86_64/firefox-72.0.1-1.fc30.x86_64.rpm

F31x32: https://kojipkgs.fedoraproject.org//packages/firefox/72.0.1/1.fc31/i686/firefox-72.0.1-1.fc31.i686.rpm

F31x64: https://kojipkgs.fedoraproject.org//packages/firefox/72.0.1/1.fc31/x86_64/firefox-72.0.1-1.fc31.x86_64.rpm

Fedora: Kernel 5.4.7 verfügbar

Mit dem Push vom Linux Kernel 5.4.7 ins stabile Repository von Fedora, hat die Nvidia HDMI Audiokrise ein Ende.

Kernel 5.4.7 verfügbar

Wie in dem Beitrag vom Dezember 2019 „Kernel 5.3.16 mit HDMI-Audio Problemen“ beschrieben, gab es ein ein kleines Problem beim korrekten Markieren von NVIDIA Audiogeräten, z.b. Monitoren mit Lautsprechern. Das wurde nicht mehr für die 5.3er Serie des Kernels behoben, obwohl es nur EIN einziger Zeichenwechsel gewesen wäre.

Wie sich damals ja schnell herausgestellt hat, wollte man mit einem Fix eigentlich ein anderes Problem bei Audiogeräten beheben, hat aber mehr kaputt gemacht, also der Fix behoben hatte. Da so ein Kernelbuild auch auf einem schnellen i7 auf SSDs mal locker 1h plus Tests dauern kann,  kann ich schon verstehen, daß man keine eigene Kernelrelease für den an sich trivialen Fix gebaut hat, zumal man einfach auf einen alten Kernel ausweichen konnte.

Es bleibt zu hoffen, daß es nicht nochmal passiert, denn es hat echt in den Ohren geklingelt.

Linux – Schneller Videos schrumpfen

Wer wie ich Videos von Spielen captured und dadurch viel Rohmaterial in großen Bitraten liegen hat, braucht die Hilfe seiner Grafikkarte um dieses Rohmaterial möglichst schnell in handhabbare Größen umzuwandeln.

Moderne Video Hardware nutzen

Das Ausgangsmaterial ist mit 5 Mb/s erstellt worden, was den Kodiervorgang beim Bildschirmcapturen beschleunigt, zum Ansehen reichen aber 2 Mb/s VBR locker aus. Früher habe ich zum Recodieren meinen Achtkerner benutzt, was schon einmal 70% der Realzeit eines Videos benötigt hat.

Heute macht das die Nvidia Grafikkarte für mich und das mit meistens 10x Geschwindigkeit meines Achtkerners 🙂

Auslastung einer Nvidia GTX1050

Wie man auf dem Bild schön sehen kann, wird die Video Engine voll ausgenutzt. Das spiegelt sich dann in so einer FFMpegausgabe wieder:

Eine Ausgabe in der Bashshell von ffmpeg beim Nutzen von Nvidia GPUs

Faktor 18 – 23 wurden im Schnitt gesichtet, kommt halt auch drauf an, ob man Schwarzbilder oder Aktion kodiert. Wie ich schon bei meinem OpenShot Artikel geschrieben habe, hängt das Endergebnis auch stark von der Resthardware des PCs ab.

FFMpeg sorgt für den Hardwaresupport

Der Befehl „ffmpeg -hwaccels“ gibt einem die für FFMpeg verfügbaren HW-Encoder aus:

$ ffmpeg -hwaccels
ffmpeg version 4.1.4 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9 (GCC)

Hardware acceleration methods:
vdpau
cuda
vaapi
qsv
drm
opencl
qsv
cuvid

Auf Nvidia-Grafikkarten sieht der Befehl zum Kodieren dann so als Script aus:

#!/bin/bash

NAME=$(basename „$1“ .mp4)

ffmpeg -hwaccel cuvid -threads 8 -c:v h264_cuvid -i „$1“ -map 0:1 -map 0:0 -c:v:0 h264_nvenc -b:v:0 2000k -c:a:0 copy -f mp4 „/home/<username>/$NAME.mp4“

Damit wird eine VBR Rate von 2.000 Kb/s, der h264_cuvid Decoder für h264 Videos und der h264_nvenc Encoder für des Reencoden genutzt. Es beschleunigt den Vorgang nämlich sehr, wenn die Grafikkarte auch Dekodiert. Die Option „-hwaccel“ gibt den zu nutzenden Treiber an.

Anmerkung: Obiges Script kann nur einen Video- und einen Audiostream verarbeiten, Dual-Ton Tracks muß man selbst einbauen.

Verscripten geht immer…

Das Script nimmt als Argument ein mp4 Video, extrahiert den Dateinamen und erzeugt das Ausgabevideo im Homeverzeichnis ( passenden Benutzernamen einsetzen ). Ein „chmod 700 script“ gepaart mit einem „mv script ~/.local/bin/“ macht das ganze dann in der eigenen Shell leicht ausführbar.

Auch für nicht Nvidia-Grafikkarten gibt es verschiedene Codecs, die die Sache beschleunigen, wie man in obiger FFMpeg Ausgabe sehen kann. Allerdings sind Nvidia-Grafikkarten die schnellsten im Test vom Linux-Magazin gewesen, aus dem ich mir meinen optimierten Befehl hergeleitet habe.Das könnte sich bei der derzeitigen Dominanz von AMD natürlich bereits geändert haben.

Infos: https://www.linux-magazin.de/ausgaben/2017/11/ffmpeg-mit-gpus/