youtube-dl: die wirklich neueste Version bekommen

Wer schon einmal ein Video von Youtube auf dem PC laden wollte, kennt das (kleine) Programm youtube-dl vielleicht. Aufgrund neuester Änderungen an den Signaturalgorithmen von Seiten Youtube’s, kommt es seit einigen Tagen zu einem Fehler, wenn man Playlisten runterladen möchte.

Latest Version, die keine ist…

Beispielhaft soll hier mal der geschlossene Bugtrackeintrag  https://github.com/ytdl-org/youtube-dl/issues/23915 gezeigt werden:

youtube-dl --verbose 'https://www.youtube.com/watch?v=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' 
[debug] System config: [] 
[debug] User config: [] 
[debug] Custom config: [] 
[debug] Command-line args: ['--verbose', 'https://www.youtube.com/watch?v=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'] 
[debug] Encodings: locale UTF-8, fs utf-8, out UTF-8, pref UTF-8 
[debug] youtube-dl version 2019.12.25 
[debug] Python version 3.6.9 (CPython) - Linux-4.15.0-64-generic-x86_64-with-LinuxMint-19-tara 
[debug] exe versions: ffmpeg 3.4.6, ffprobe 3.4.6 
[debug] Proxy map: {} 
 I8KSAtos-dk: Downloading webpage 
 I8KSAtos-dk: Downloading video info webpage 
 {18} signature length 106, html5 player vfl1GpCbm 
 I8KSAtos-dk: Downloading player https://www.youtube.com/yts/jsbin/player_ias-vfl1GpCbm/en_US/base.js 
ERROR: Signature extraction failed: Traceback (most recent call last): 

Von der Sorte prasseln auf die Entwickler bei GitHub derzeit einige pro Tag ein, die alle mit „added the outdated-version label Jan 31, 2020“ abgeschmettert werden.

Jetzt könnte man ja meinen, daß es da einen Updatemechanismus gibt, den man benutzten könnte, um an die neuste Version zu kommen. Laut der Projektseite: https://github.com/ytdl-org/youtube-dl gibt es den natürlich auch:

To install it right away for all UNIX users (Linux, macOS, etc.), type:

sudo curl -L https://yt-dl.org/downloads/latest/youtube-dl -o /usr/local/bin/youtube-dl
sudo chmod a+rx /usr/local/bin/youtube-dl

Wenn man das tut, bekommt man aber nicht die neueste Version, sondern die 2019.11.28 angeboten. Starrsinnigerweise beharren die Entwickler trotz gegenteiliger Beweise darauf, daß man doch die latest Version nehmen sollte. Sie nennen das die „Binary“ Version. Bloß, wo bekommt man die her?

Wo man es her bekommt

Unter https://github.com/ytdl-org/youtube-dl/releases kann man sich eine Version namens youtube-dl laden. Die kann man einfach nach /usr/local/bin/ kopieren, wo die alte Version bereits liegt. Beim Kopieren solltet Ihr die Rechte nicht verändern. Zur Not einfach „sudo chmod a+rx /usr/local/bin/youtube-dl“ hinterher ausführen.

Damit hätte man dann die „latest version“, die in den Bugtracker Ablehnungen gemeint ist. Vielleicht sollten die Entwickler mal Ihre Updatebeschreibung überdenken oder Ihren kleinen Versionsfehler auf dem Server aus der Anleitung fixen.

Interessant an der Sache finde ich nur, daß es ein ZIP Files ist und Linux das zur Laufzeit auspackt und an Python weiter gibt. Hätte ich nicht vermutet, daß das geht.

verfrühtes Ende von Elster

Wir wußten ja, daß das Elster auf dem Desktop keine all zu lange Zukunft mehr hat, aber das Kapitel jetzt durch einen Bug vorzeitig beendet wird, ist schon überraschend.

Beim Update hops gegangen

Seit Tagen suche ich nach einer anderen Lösung als Elster Online benutzen zu müssen, aber leider ging das nicht mehr. Ob das jetzt an meiner Wineumgebung, oder dem neuen Wine 5 liegt, Fakt ist, es updatet nicht mehr und zerstörte beim missglückten Update auch noch den Signator von Eric ( das ist das eigentliche Elster ). Kurz um: nichts sinnvolles geht mehr, außer alten Unterlagen beim digitalen Verwesen zu zusehen.

Da hat wohl eine Datei im Archiv vom Update gefehlt:

0067:err:module:import_dll Library libcrypto-1_1.dll (which is needed by L“C:\\Program Files\\ElsterFormular\\bin\\ericprozess.exe“) not found

Macht Euch also darauf gefasst, gleich die Online Version nehmen zu müssen. Auch wenn man Elster einiges Nachsagen kann, aber die Onlineversion ist noch schlimmer, weil total unübersichtlich.

R.I.P. Eric.

Thunderbird < 68.4.1mit RCE Schwachstelle

Und gleich nach Firefox zieht Mozilla mit der (vermutlich) gleichen Schwachstelle in Thunderbird nach: Remote-Code-Execution in Version < 68.4.1

Remote-Code-Execution in Thunderbird

Wie wir gerade vom CERT erfahren haben, ist in Thunderbird eine Sicherheitslücke enthalten, die zum Ausführen von Code aus der Ferne taugt. Mozilla schreibt dazu:

CVE-2019-17024: Memory safety bugs fixed in Thunderbird 68.4.1

Reporter Mozilla developers
Impact high
Description

Mozilla developers Jason Kratzer, Christian Holler, and Bob Clary reported memory safety bugs present in Thunderbird 68.3. 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.

References   Memory safety bugs fixed in Thunderbird 68.4.1

Eine weitere kritische Sicherheitslücke wurden auch gefunden, auch wenn diese nicht per Email ausgenutzt werden kann:

Announced January 10, 2020
Impact critical
Products Thunderbird
Fixed in Thunderbird 68.4.1

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-2019-17026: IonMonkey type confusion with StoreElementHole and FallibleStoreElement

Reporter Qihoo 360 ATA
Impact    critical
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.
References  Bug 1607443

 

Offensichtlich nutzen Angreifer das bereits aus, weil der gleiche Bug auch in Firefox drin war. Wie das genau dann passiert, kann ich mir allerdings auch nur schwer vorstellen.

Derzeit werden die nötigen Pakete bei Fedora noch gebaut! Es gibt also noch keine Updates, die man einspielen könnte für Euch. Andere Distributionen waren da ggf. schneller.

Update

Hier Eure Downloadlinks:

https://kojipkgs.fedoraproject.org//packages/thunderbird/68.4.1/1.fc30/x86_64/thunderbird-68.4.1-1.fc30.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/thunderbird/68.4.1/1.fc31/x86_64/thunderbird-68.4.1-1.fc31.x86_64.rpm

Fedora: Firefox 72.0.1 läuft

Wie gestern gemeldet gab es auf einigen PCs Probleme mit dem Fedora 30 Update von Firefox 72.x: Warnung: FireFox 72.x inoperabel.

NSS als Ursache

Als Ursache konnte jetzt NSS ausgemacht werden, daß auf einigen Systemen bereits ein nötiges Update erfahren hatte, auf anderen aber noch nicht installiert war. Da im Firefox RPM keine Abhängigkeit auf eine spezielle mindestversion von NSS vermerkt ist, hat DNF in dem Fall nicht gemeckert, was sonst die Folge gewesen wäre, wenn Versionen nicht stimmen.

Wer das Firefox-Update einspielen will, sollte zuerst sein normales System mit „dnf update“ auf Stand bringen, dann klappt es auch mit dem neuesten Firefox wieder.

Linux-Umstiegsabend: Was sind die Alternativen?

Am Mittwoch, den 29.1.2020 veranstaltet die BS-LUG wieder einen Umsteigerabend für bisherige Windowsbenutzer im Haus der Talente. Diesmal zeigen wir aktiv auf, welche Programme man als Ersatz für seine Windowsprogramme benutzen kann.

„Umsteigen auf LINUX, leicht gemacht!“

Beim gestrigen Brainstorming zum Thema, kamen nach anfänglichen Zögern, einige interessante Ansätze welche Programme man da auflisten müßte. Ziel ist es dem Besucher den Umstieg von Windows (7) so einfach wie möglich zu machen.

Zeit: 29.1.2020 um 18:00 Uhr
Ort: Haus der Talente
Elbestr. 45

Programmplan: https://bs-lug.de

Kommen kann natürlich wieder jeder der sich für einen Umstieg interessiert. Für das leibliche Wohl wird natürlich auch wieder gesorgt.

 

Warnung: FireFox 72.x inoperabel

Erste Rückmeldungen zu Firefox 72.0 und 72.0.1 zeigen leider ein besorgnisergendes Verhalten. Auf einigen PCs starten die neuen Firefoxe zwar, zeigen aber keinen Content mehr an.

Ersten Nachforschungen nach könnte ein RECHTEPROBLEM die Ursache sein, da die Rendersubprozesse ein EACCESS bei einigen Zugriffen bekommen. Das ist aber noch höchst spekulativ.

Betroffen ist min. die 64Bit Version von Fedora 30. Diese hatte auch schon im Buildprozesse einige Fehler aufzuweisen, die offensichtlich nicht ganz unbegründet waren. Mehr dazu, wenn ich es erfahre!

Update:

Netzwerkverkehr, also Abrufen von Seiten findet statt, aber das Rendering der Webseite failed. Interessanterweise werden die Internen „Seiten“ wie Addons und Einstellungen angezeigt. Mehr Neuigkeiten, oder gar ein Muster, gibt es leider noch nicht.

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

PHP: kleines Problem in 7.3 mit . + –

Da meldet sich doch mein Kalender heute mit der Meldung, er könnte den Termin nicht modifizieren, weil der Server einen 500er Fehler produziert hat. Der Aufruf des Webinterfaces verlief zunächst einmal ohne Befund.

PHP 8 ist bald da!

Der eigentliche Fehler im Script ist eigentlich ganz einfach, hat aber große Auswirkungen auf PHP Programme. Ich wage sogar die These, daß dieser Fehler in PHP 8 zu einem Y2K Problem wird: Fixbar, aber es wird trotzdem knallen.

Kleine Einführung, damit Sie dem auch folgen können:

PHP ist eine Programmiersprache die auf Webservern zum Einsatz kommt.

E= 3+1  ergibt E=4  ( Addition )
E= 3-1    ergibt E=2  ( Subtraktion )
„Hallo“ . “ “ . „Welt“  ergibt in PHP „Hallo Welt“
„Obj->F“ meint, Zugriff auf ein FELD (F) im Objekt (Obj) , wird in der Objektorientierten Programmierung von PHP benutzt. „$this->“ meint dabei das Objekt in dessen Kontext die Operation ausgeführt wird, sprich „meint sich selbst“.

„+-“ sind nummerische Operationen,  „.“ ist eine lexikalische Anweisung auf Textblöcke in PHP.

Schauen wir uns erstmal den Fehler an, den SabreDAV hier als Kalenderbackend produziert:

[Wed Jan 08 16:03:28.700531 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] PHP Fatal error: Uncaught ErrorException: The behavior of unparenthesized expressions containing both ‚.‘ and ‚+’/‘-‚ will change in PHP 8: ‚+’/‘-‚ will take a higher precedence in /home/<username>/cal/vendor/sabre/vobject/lib/Sabre/VObject/RecurrenceIterator.php:829: <cgiwrapper>
[Wed Jan 08 16:03:28.700685 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] Stack trace:: <cgiwrapper>
[Wed Jan 08 16:03:28.700946 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #0 /home/<username>/cal/vendor/composer/ClassLoader.php(386): exception_error_handler(): <cgiwrapper>
[Wed Jan 08 16:03:28.701145 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #1 /home/<username>/cal/vendor/composer/ClassLoader.php(386): include(): <cgiwrapper>
[Wed Jan 08 16:03:28.701369 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #2 /home/<username>/cal/vendor/composer/ClassLoader.php(278): Composer\\Autoload\\includeFile(): <cgiwrapper>
[Wed Jan 08 16:03:28.701539 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #3 [internal function]: Composer\\Autoload\\ClassLoader->loadClass(): <cgiwrapper>
[Wed Jan 08 16:03:28.701741 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #4 /home/<username>/cal/lib/Sabre/CalDAV/Backend/PDO.php(520): spl_autoload_call(): <cgiwrapper>
[Wed Jan 08 16:03:28.702034 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #5 /home/<username>/cal/lib/Sabre/CalDAV/Backend/PDO.php(461): Sabre\\CalDAV\\Backend\\PDO->getDenormalizedData(): <cgiwrapper>
[Wed Jan 08 16:03:28.702503 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #6 /home/<username>/cal/lib/Sabre/CalDAV/CalendarObject.php(96): Sabre\\CalDAV\\Backend\\PDO->updateCalendarObject(): <cgiwrapper>
[Wed Jan 08 16:03:28.702713 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #7 /home/<username>/cal/lib/Sabre/DAV/Server.php(888): Sabre\\CalDAV\\CalendarObject->put(): <cgiwrapper>
[Wed Jan 08 16:03:28.703037 2020] [cgid:error] [pid 15227:tid 140702835001088] [client 83.246.80.131:60598] #8 [internal function]: Sabre\\DAV in /home/<username>/cal/vendor/sabre/vobject/lib/Sabre/VObject/RecurrenceIterator.php on line 829: <cgiwrapper>

Da wird also die fehlende Klammerung von Operationen mit „.“ „-“ oder „+“ angekreidet. Erstmal komisch, bis man den Sourcecode dazu sieht:

$this->currentDate->modify(‚+‘ . $this->interval-1 . ‚ weeks‘);

PHP 7.3 meckert hier also darüber, daß der Entwickler davon ausgeht, daß eine mathematische Operation Vorrang vor einer lexikalischen Operation hat. Vom Ablauf steht dort in etwa:

$TVAR = $this->interval
$TVAR = $TVAR – 1
$TSTRING1 = StringAusZahl( $TVAR )
$TSTRING2 = FügeStringsZusammen( „+“, $TSTRING1, “ weeks“ )
RufeFunktionAuf(  $this->currentDate->modify , $TSTRING2 )

Das geht nur, weil der Operator „-“ hier Vorrang hat im Parser. Wenn das nicht mehr der Fall ist, also „.“ gleichrangig mit „-“ wäre, dann knallts, weil dann käme das raus ( oder noch etwas völlig anderes ):

$TVAR = $this->interval
$TVAR = $TVAR – „1 weeks“

Und hier wäre es dann auch schon vorbei, weil das nicht geht. Man kann keinen String von einer Zahl abziehen. Deswegen muß man jetzt eine Klammerung vornehmen, die eindeutig macht, was da wie subtrahiert werden soll und was dann als Zahl behandelt werden soll.

IMHO wäre das schon ein ParserBug in PHP 0.1 gewesen, der es nie in die Stable von PHP hätte schaffen dürfen. Das Parserverhalten jetzt in PHP 7.3 zu ändern bricht ziemlich hart mit vorhandenem Code und wird totsicher für Probleme rund um den Globus führen.

So müßte es jetzt für PHP 7.3 + PHP 8 geändert werden, damit es später noch funktioniert:

$this->currentDate->modify(‚+‘ . ($this->interval-1) . ‚ weeks‘);

Jetzt ist klar, daß hier „-“ Vorrang vor „.“ hat. Problem gelöst.

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.

Exploit in NetHack < 3.6.4

Weil es so ungewöhnlich ist, muß ich Euch kurz mitteilen, daß in Nethack, genau, dem Textadventure von Anno 1980 🙂 ein Loch ist. Naja, genau genommen, der aktuellen Version davon, wobei, „aktuell“ ist es jetzt auch nicht mehr 😉

NetHack: Privilege escalation/remote code execution/crash in configuration parsing

Die Meldung vom Dev Team von NetHack:

Severity: High
Affected versions: 3.6.0, 3.6.1, 3.6.2, 3.6.3
First Patched Version: 3.6.4

CVE-2019-19905

Basic Information:
A buffer overflow issue exists when reading very long lines from a NetHack configuration file (usually named .nethackrc).

This vulnerability affects systems that have NetHack installed suid/sgid and shared systems that allow users to upload their own configuration files.

All users are urged to upgrade to NetHack 3.6.4 as soon as possible.

Additional information related to this advisory, if any, will be made available at https://nethack.org/security.

Also jeder der NetHack einsetzt sollte darauf achten, keine fremden Konfigs zu benutzen, oder einfach mal auf 3.6.4 updaten. Fedora stellt die Updates bereits zur Verfügung.

Kleine Anmerkung: Ich hab es mal ausprobiert. Früher(tm), an der Uni hatten wir ja MUD im Einsatz, welches mir in der Erinnerung deutlich bedienerfreundlicher vor kommt, als das NetHack hier. Die unlogische Tastaturbelegung ist vermutlich historisch begründet, aber wenn man das 40 Jahre pflegt, könnte man doch auch mal mehr Platz auf der Map und eine intuitivere Steuerung einbauen, oder wäre das zu viel verlangt? Ja, es wäre nicht mehr das NetHack von 1980, aber was ist so schlimm dran? Der Ghostbusters 4 Film sieht auch besser aus, als Teil 1 von 1980 😉