Das Projekt uutils hat Version 0.5.0 seiner Rust Coreutils veröffentlicht. Die in Rust geschriebene Neuimplementierung klassischer Unix-Kommandozeilenprogramme erreicht damit 87,75 Prozent Kompatibilität zur GNU-Test-Suite – ein Anstieg um knapp zwei Prozentpunkte gegenüber Version 0.4.0. Von insgesamt 645 Tests bestehen die Rust Coreutils nun 566, während 55 fehlschlagen, 23 übersprungen werden und einer zu einem Fehler führt.

Die Entwickler haben die Referenz-Test-Suite von GNU Coreutils 9.8 auf 9.9 aktualisiert, wodurch elf neue Tests hinzukamen. Trotz dieser zusätzlichen Prüfungen konnten 22 weitere Tests erfolgreich absolviert werden. Besonders hervorzuheben sind Verbesserungen bei den Utilities fold, cksum, install, numfmt und seq. Das Tool fold unterstützt nun kombinierende Unicode-Zeichen für korrekte Textumbrüche, während cksum mit hashsum zusammengeführt wurde und nun eine einheitliche Checksum-Funktion bietet.

Plattform-Unterstützung ausgebaut

Mit Version 0.5.0 erweitert das Projekt seinen Plattform-Support erheblich. OpenBSD wurde in die CI-Pipeline aufgenommen, die Redox-OS-Unterstützung reaktiviert und der Cygwin-Support in der uucore-Bibliothek verbessert. Als Folge hiervon können nun zehn zuvor übersprungene Tests ausgeführt werden. Die Rust Coreutils laufen damit offiziell auf Linux-Distributionen wie Ubuntu 25.10, FreeBSD, OpenBSD, Windows via Cygwin und dem experimentellen Betriebssystem Redox.

Canonical hatte bereits angekündigt, die Rust Coreutils in Ubuntu standardmäßig einzusetzen – primär aufgrund der Vorteile von Rust in puncto Speichersicherheit. Die Version 0.3.0 hatte bereits gezeigt, dass das sort-Tool in CPU-lastigen Szenarien bis zu 3,7-mal schneller arbeitet als sein GNU-Pendant – andere Tools wie expand (1,8×) oder nl (1,57×) zeigen ebenfalls deutliche Geschwindigkeitsgewinne als die GNU-Pendants. Bei IO-gebundenen Operationen fallen die Unterschiede geringer aus.

Noch 12 Prozent bis zur vollen Kompatibilität

Trotz der Fortschritte gibt es weiterhin Herausforderungen. Von den 55 fehlgeschlagenen Tests betreffen einige kritische Edge-Cases bei Tools wie cksum (crc32b mit --raw-Flag), od (Floating-Point-Operationen) und chroot. Auf GitHub verzeichnet das Projekt rund 380 offene Issues, die sich mit verbliebenen Inkompatibilitäten befassen. Für Administratoren, die einen produktiven Einsatz erwägen, empfehlen sich umfangreiche Tests der eigenen Skripte – insbesondere solche mit GNU-spezifischen Flags oder ungewöhnlichen Optionskombinationen.

Die Sicherheitsvorteile von Rust kommen bei den Coreutils zum Tragen: Speicherfehler wie Buffer-Overflows und unsichere Path-Traversal-Operationen gehören der Vergangenheit an. Tools wie chmod nutzen bereits sichere Traversierungsmethoden. Allerdings warnen Kritiker vor neuen Fehlerklassen, die durch Rust-spezifische Ownership-Semantik entstehen könnten. Im Gegensatz zu den jahrzehntelang gehärteten GNU Coreutils ist die Rust-Variante noch vergleichsweise jung.

An Version 0.5.0 haben sechs neue Contributor mitgewirkt. Das Projekt ruft zu Übersetzungen via Weblate auf und bittet um Unterstützung über GitHub Sponsors. Die Maintainer-Basis umfasst etablierte Entwickler wie Sylvestre Ledru von Debian und Daniel Hofstetter, der in einem iX-Interview die langfristigen Ziele des Projekts erläuterte.

Für Distributionen stellt sich die Frage nach der Paketierung: Ubuntu 25.10 setzt die Rust Coreutils standardmäßig ein, Nutzer können per apt purge coreutils-from-uutils zu den GNU-Varianten zurückkehren. FreeBSD bietet einen Port über FreshPorts an. Die MIT-Lizenz der Rust Coreutils ist mit der GPL der GNU Coreutils kompatibel und erlaubt eine problemlose Integration in Distributionen.

Die Download-Binaries für Version 0.5.0 stehen auf der Projekt-Website und über die GitHub-Releases bereit. Anwender sollten vor einem produktiven Einsatz die Test-Coverage-Dokumentation konsultieren und kritische Workflows prüfen.

(fo)

In der Webentwicklung schreiben wir nicht nur neue Software, sondern es erreichen uns natürlich auch Fehlermeldungen. Meistens können wir schnell helfen oder den Bugfix auf jeden Fall für einen der nächsten Sprints einplanen. Aber manche Fehler sind hartnäckiger und haben am Ende eine ganz simple Ursache. Um solch einen Fehler geht es heute.

Eine Zeit lang erreichten uns immer mal wieder Berichte, dass bei Usern die Verbindung zu www.heise.de mit der Meldung ERR_HTTP2_PROTOCOL_ERROR nicht zustande kam. Schnell kristallisierte sich heraus, dass die betroffenen User noch ein paar Gemeinsamkeiten hatten: Alle nutzten Chrome als Browser und waren regelmäßige Besucher unseres Angebots. Damit war der Fehler zwar schon etwas eingegrenzt, aber unser größtes Problem war: Wir selbst konnten den Fehler lange Zeit nicht nachstellen.

Viele Kekse

Die Überlegungen gingen dennoch weiter. Was sammeln User (leider heutzutage) zuhauf, wenn sie auf einem weitgehend werbefinanzierten Angebot wie heise online unterwegs sind? – Cookies. Ein Test mit betroffenen Usern sorgte dann immerhin für einen Workaround: Cookies löschen half.

Zunächst hatten wir die Cookie-Größe im Verdacht und testeten mit besonders großen Cookies, aber auch damit ließ sich das Problem für uns nicht reproduzieren. Doch dann meldete sich ein Kollege aus der Redaktion mit demselben Fehler – er bekam ihn sogar regelmäßig. Wir baten ihn um Hilfe bei der Lösung, und er gab Bescheid, sobald der Bug erneut auftrat. Endlich konnten wir das Problem direkt beobachten.

Mit tcpdump schnitten wir den Netzwerkverkehr zwischen uns und dem Browser auf dem Load-Balancer (BigIP) mit, der TLS und HTTP2 termininiert. Dabei stellte sich heraus, dass BigIP selbst die HTTP2-Verbindung wegen eines „Protokollfehlers“ beendete. Da heise online nicht einfach eine direkte Verbindung vom Browser des Users zu unserem Webserver hat, sondern noch diverse (Netzwerk-)Infrastruktur dazwischen liegt, war es für uns schon mal sehr hilfreich, den Punkt ausfindig zu machen, an dem die Verbindung bricht und welcher Teil in der Kette diesen Abbruch auslöst.

Blick in die Bug-Reports

Mit den gewonnenen Erkenntnissen durchforsteten wir die Chrome-Bug-Reports. Bei einem Report war ein HTTP2-Protokoll-Mitschnitt angefügt, bei dem wir sehen konnten, dass Chrome jeden Cookie im HTTP2-Request mit einem separaten Set-Cookie-Header sendete. Das brachte uns auf die Idee, statt der Cookie-Größe einfach mit der schieren Anzahl zu experimentieren, und siehe da: Mit sehr vielen, kleinen Cookies ließ sich das Problem reproduzieren.

Ab hier wurde es dann einfach. Mithilfe unserer Admins fanden wir eine Einstellung in der BigIP, die die maximal zulässige Anzahl der Header setzte. Dieses Limit verschoben wir nun deutlich nach oben und schon war das Problem gelöst. Jedenfalls fürs Erste, denn natürlich ist das neue höhere Limit mit noch mehr Cookie-Headern ebenfalls wieder erreichbar, und der Fehler käme zurück.

Am Fehler sind aber noch ein paar Dinge interessant. In HTTP/1.x waren mehrere Cookie-Header noch unzulässig (siehe RFC 6265), in HTTP/2 hingegen kann der User Agent jedes Cookie als einzelnen Header senden (siehe RFC 7540) und genau das hat Chrome hier getan. Dieses Verhalten ist offensichtlich eine Optimierung, denn das Übertragen sich wiederholender Header lässt sich in HTTP/2 mit der HPACK-Header-Komprimierung (siehe RFC 7541) enorm optimieren. Das funktioniert aber nur für Header, die sich nicht ständig ändern. Ein großer Cookie-Header für alle Cookies müsste also immer wieder komplett neu übertragen werden, sobald sich auch nur ein einzelnes Cookie ändert.

Chrome zeigte leider in den Developer-Tools nichts davon an. Dort wird immer nur ein Cookie-Header gelistet, was die Fehlersuche nicht unbedingt erleichtert hat.

Ob das nun eine Problemlösung oder lediglich ein großes Pflaster ist, wird die Zeit zeigen. Die Ursachenforschung war aber definitiv mal wieder eine der interessanteren Recherchen im Developer-Alltag.

(rme)

Die Patches zum Schließen einer kritischen Sicherheitslücke im React-Server sind unvollständig, erklärt Meta. Admins sollen umgehend die neuen Aktualisierungen anwenden, um weitere entdeckte Sicherheitsprobleme auszubessern, empfiehlt das Unternehmen.

In einem Blog-Beitrag erklären die React-Entwickler, dass die zuvor veröffentlichten Patches anfällig sind. „Wenn du bereits die Updates gegen die kritische Sicherheitslücke in der vergangenen Woche angewendet hast, musst du nochmal aktualisieren“, schreiben sie in einem hervorgehobenen Eintrag. „Wenn du auf 19.0.2, 19.1.3 oder 19.2.2 aktualisiert hast, sind diese [Patches] unvollständig und du musst noch einmal aktualisieren“, präzisieren sie.

Weitere Lücken gefunden

IT-Sicherheitsforscher haben demnach drei weitere Sicherheitslücken in den React-Server-Komponenten entdeckt, als sie versucht haben, die Patches aus der Vorwoche zu missbrauchen. Die neuen Schwachstellen ermöglichen kein Einschleusen und Ausführen von Schadcode, die bisherigen Patches unterbinden diesen Angriff zudem effektiv, ergänzen die React-Entwickler. Neu sind Denial-of-Service-Lücken (CVE-2025-55184, CVE-2025-67779, CVSS 7.5, Risiko „hoch“) und eine Schwachstelle, die Sourcecode exponieren kann (CVE-2025-55183, CVSS 5.3, Risiko „mittel“). Die Schwachstellen finden sich in denselben Paketen und Versionen wie die bereits aktiv missbrauchte Sicherheitslücke (CVE-2025-55182, CVSS 10.0, Risiko „kritisch“).

Betroffen sind die Versionen 19.0.0, 19.0.1, 19.0.2, 19.1.0, 19.1.1, 19.1.2, 19.2.0, 19.2.1 und 19.2.2 von „react-server-dom-webpack“, „react-server-dom-parcel“ und „react-server-dom-turbopack“. In den Fassungen 19.0.3, 19.1.4 und 19.2.3 haben die Programmierer die sicherheitsrelevanten Fehler korrigiert.

​Googles Threat-Intelligence-Team hat zum vergangenen Wochenende Erkenntnisse über laufende Angriffe auf die „React2Shell“ genannte Lücke CVE-2025-55182 zusammengefasst. Demnach hat Google kurz nach Bekanntwerden des Sicherheitslecks Anfang Dezember weitreichende Exploit-Versuche auf viele Cluster beobachtet, die von opportunistischem Cybercrime bis zu der Spionage verdächtigen Gruppierungen ausgehen. Google nennt von China ausgehende Spionageversuche, finanziell motivierte Aktivitäten und auch Attacken aus dem Iran. In den Kampagnen haben die Täter versucht, etwa Minocat-Tunneler, Snowlight-Downloader, Hisonic- und Compood-Backdoors sowie Krypto-Miner zu installieren. Einige der Beobachtungen überschneiden sich mit denen des IT-Sicherheitsunternehmens Huntress sowie mit weiteren bereits beobachteten Angriffen auf die Lücke.

(dmk)