OpenSSL in Fedora 39 kann keine Legacy-Policy mehr

Allem Anschein nach, wurde der Support für TLSv1 und TLSv1_1 in der aktuellen OpenSSL Version für Fedora 39 hard entfernt, denn entgegen der LEGACY policy von Fedora, funktioniert TLS1 gar nicht mehr.

OpenSSL in Fedora 39 kann keine Legacy-Policy mehr

Es gibt so Dinge, die man durch Update bereinigen kann, aber oft passiert leider auch das Gegenteil, man handelt sich Legacy Probleme ein. So geschehen durch ein Server-Update auf Fedora 39.

Der spezielle Server wird von Clienten kontaktiert, die aus Gründen mit TLS1 um die Ecke kamen. Leider mag Fedora das seit 33 gar nicht mehr und das ist auch gut so. Bislang half es, einfach die Crypto-Policy auf Fedora 32 zu stellen:

update-crypto-policies –set DEFAULT:FEDORA32

Die Hardcore version davon ist dann der LEGACY mode :

update-crypto-policies –set LEGACY

der wirklich uralte Sachen aktiviert. Bislang. Seit Fedora 39 kann man soviel Legacysupport aktivieren wie man will, es nutzt nichts mehr, TLS 1 und 1.1 funktionieren nicht mehr.

Dies hatte eine wünschenswerte Folge, denn nun war jemand gezwungen seine Legacy-Clienten zu Updaten, was schon seit Jahren hätte gemacht werden sollen 😉

Jetzt konnten wir endlich den Support auf DEFAULT stellen \o/

update-crypto-policies –set DEFAULT

Merke: Es ist nie gut eine Rückzugsmöglichkeit im Kryptobereich zu haben, weil dann die Updates nicht gemacht werden mit „Wieso, geht doch noch.“ ;D

Neues aus der Linuxwerkstatt: Pipewire verantwortlich?

An manchen Tagen komme ich mir vor, als wenn ich eine Linuxwerkstatt hätte, statt einen PC mit einer Stableversion von Fedora. Da bin ich öfters im Redhat Bugtracker als auf meiner eigenen Webseite.

Neues aus der Linuxwerkstatt: Pipewire verantwortlich?

Der.. nein, sagen wir lieber „ein“ aktueller Fall in der Werkstatt ist das Unvermögen von Firefox Netflix über Wochen sauber abzuspielen ohne Probleme auf die oder andere Art zu produzieren.

Was war geschehen?

Am 2. Mai hatte Firefox beschlossen, daß ich zwar von Netflix den Ton hören dürfte, aber das Video wäre jetzt Privatsache vom Videodecoder. Die Bilder stockten also, insgesamt war alles im Firefox zäh wie Sirup. Die Probleme mit Netflix dauerten auch bis in den nächsten Tag an, wobei auch Webseiten sirupartig waren. Auf einem Ryzen 5600 mit RTX 4060 ist das eher kein Hardwareproblem.

Der Verdacht lag nahe, daß Firefox statt die GPU zu verwenden beschlossen hatte die CPU die ganzen bunten Dinge berechnen zu lassen, was zu immensen Performanceproblemen führen würde. Nach ein paar Stunden des selben Tages gab sich das Problem, was aber nicht an Firefox lag wie sich rausstellte.

Da es ein gstreamer Update gab, daß zeitlich korrelierte, habe ich mal ein Ticket im Bugzilla von Redhat aufgemacht, prompt hat sich da ein anderer User gemeldet, der ähnliche Probleme mit Firefoxplayback auf einer AMD RT 6800 hatte.

Die Zeit vergeht… alle sind ratlos

Die zeit vergeht, alle sind ratlos, dann schlägt das Schicksal erneut gnadenlos zu: Letzte Nacht stoppt Netflix mit dem gleichen Problem während ich ein Video mit OpenShot geschnitten habe. Also erstmal Firefox neugestartet, aber das half nichts. Dann gesagt: „nicht so wichtig“ und mich ums Video gekümmert. Das habe ich mir mit Celluloid ansehen wollen und was muß ich feststellen? Kein Videoplayback, nur Ton. „Oh oh“

Nichts geht mehr

Celluloid, MPV, Totem produzierten ALLE das gleiche Muster, nicht mal die Fortschritte auf den Zeitskalen wurden durchgezählt, die Videos zeigten nur das erste Bild vom Video was üblicherweise Schwarz ist, so daß man das nciht direkt merkt. Zum Glück hatte ich ein anderes Video das direkt ein Bild da hatte. Skippe man im Video rum, kamen auch anderen Standbilder raus.

Um Kernelprobleme auszuschließen habe ich rebooted, aber das half rein gar nichts. Alle Videoplayer zeigten das gleiche Bild ( sprichwörtlich ) … „wirklich alle?“ Nein, ein kleiner, oft völlig unbedachter Videoplayer trotzte dem Problem und spielte weiterhin alle Videos perfekt ab. Und an dem Punkt geht einem ein Licht auf.

Der Player war FFPLAY from FFMPEG Paket. Das heißt, alle anderen Videoplayer und Firefox müssen etwas gemeinsam haben: Pulseaudioplayback.

Der Workaround

Ums Kurz zu machen: sobald jemand via Pulseaudio auf das den HDMI Ausgang meiner Nvidiakarte wollte, stockte das Video, aber der Ton ging sauber durch, was  völlig GAGA ist, weil das kein bisschen was mit Grafiken zu tun hat.

Ich denke folgendes ist passiert: Pipewire läuft ja unter der Haube von Pulse und ist für Video und Audio zuständig. Das hat ein Problem mit dem HDMI Device gehabt. Das muß aber in der User-Config persistent gespeichert sein, also quasi blanker Unsinn im State File oder so etwas in der Art, weil es ja rebootfest war und das geht nur, wenn sich jemand den „Zustand“ von dem Device irgendwo auf der Platte merkt!

Ich habe dann einfach mal das Device via PulseAudio-Lautstärkeregler abgeschaltet, so daß alle Audiostreams über das Mainboard liefen und was soll ich sagen : 100% alle Probleme verschwunden. Alle Player funktionierten wieder 1a.

Nach dem das Ausgabegerät wieder auf dem selben Weg eingeschaltet wurde, liefen die Player auch mit dem HDMI Gerät wieder einwandfrei.

Im Bugtracker wird fleißig am Problem gearbeitet, sollte also bald gefixt sein.

Linux am Dienstag – Programm für den 14.5.2024

Sommerloch, aber wir lassen uns mal überraschen was es heute gibt, aber ich denke, es wird was mit Ipv6 zu tun haben.

Linux am Dienstag – Programm für den 14.5.2024

u.a. im Programm am 7.5.2024, ab 19 Uhr:

ASUS – Herbe Kritik am Kundensupport
Thema – Mal sehen was wir heute machen 🙂
Sicherheit – EuroPol erneut gehackt
Datenschutz – Vorratsdatenspeicherung vom EUGH im Rahmen erlaubt
Sicherheit – VW ahmt Cisco nach und verteilt hardkodierte Passwörter für DB Zugriff

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .