Datumsfehler in Rust-basierten coreutils stoppt automatische Updates unter Ubuntu 25.10

• Unter Ubuntu 25.10 tritt durch einen Bug im in Rust geschriebenen coreutils(uutils)-Befehl date auf einigen Systemen ein Problem auf, bei dem die automatische Update-Funktion nicht funktioniert
• Der Bug wurde in rust-coreutils-Paketen bis Version 0.2.2-0ubuntu2 gefunden und in Version 0.2.2-0ubuntu2.1 und neuer behoben
• Das Problem betraf Cloud-Bereitstellungen, Container-Images sowie Desktop- und Server-Installationen, hatte jedoch keine Auswirkungen auf manuelle Updates über den Befehl apt
• Ubuntu testet in diesem Release den Wechsel zu Rust-basierten Utilities (uutils, sudo-rs), um eine mögliche Übernahme in die Langzeitunterstützungsversion (LTS) im nächsten Jahr zu bewerten
• Der Vorfall zeigt die Notwendigkeit einer Stabilitätsprüfung im Zuge der Rust-Migration und liefert wichtige Hinweise für die künftige Sicherheits- und Wartungsstrategie von Distributionen

---

Überblick über die Störung der automatischen Updates in Ubuntu 25.10

• Das Ubuntu-Projekt hat offiziell bekannt gegeben, dass einige Systeme wegen eines Bugs im date-Befehl des Rust-basierten uutils nicht automatisch nach Updates suchen konnten
  • Zu den betroffenen Systemen gehörten Cloud-Bereitstellungen, Container-Images sowie Ubuntu-Desktop- und -Server-Installationen
  • Durch das Scheitern der automatischen Update-Prüfung bestand das Risiko verzögerter Sicherheits-Patches und Software-Aktualisierungen
• Das Ubuntu-Sicherheitsteam stellte in einer Mitteilung Anweisungen zur Behebung (remediation instructions) bereit
  • Nutzer müssen das Paket rust-coreutils auf Version 0.2.2-0ubuntu2.1 oder neuer aktualisieren, um das Problem zu beheben
  • Der Bug betrifft ausschließlich den automatischen Update-Prozess; der Befehl apt und andere manuelle Update-Werkzeuge sind nicht betroffen

Ursache des Bugs und Umfang der Auswirkungen

• Als Ursache gilt, dass der in Rust neu geschriebene coreutils(uutils)-Befehl date bei der Verarbeitung der Systemzeit einen Fehler auslöste
  • Dadurch scheiterte der Scheduler für automatische Updates an der korrekten Datumsberechnung, und die Update-Prüfroutine wurde unterbrochen
• Der Fehler betraf sämtliche Bereitstellungsformen von Ubuntu 25.10, insbesondere mit möglichem Betriebsrisiko in automatisierten Serverumgebungen und Cloud-Instanzen
• Ubuntu erkannte durch diesen Vorfall die Notwendigkeit, die Verfahren zur Stabilitätsprüfung von Rust-basierten System-Utilities zu verschärfen

Umstellung auf Rust-basierte Utilities (Projekt „Oxidize“)

• Ubuntu treibt in Release 25.10 das Projekt „oxidize“ voran und experimentiert damit, die bisherigen C-basierten coreutils durch Rust-basierte uutils zu ersetzen
  • Gleichzeitig wird auch die Rust-Version des sudo-Befehls (sudo-rs) eingeführt, um Sicherheit und Speichersicherheit zu verbessern
• Das Projekt ist eine Testphase, um zu bewerten, ob Rust-basierte Utilities in das für April 2026 geplante LTS-Release aufgenommen werden können
• LWN hatte das Projekt bereits im März 2025 behandelt und die Auswirkungen der Rust-Einführung auf die strukturelle Stabilität von Linux-Distributionen analysiert

Behobene Version und Handlungsempfehlungen

• Laut Ubuntu-Sicherheitshinweis enthalten Versionen von rust-coreutils bis einschließlich 0.2.2-0ubuntu2 das Problem
  • Mit einem Update auf 0.2.2-0ubuntu2.1 oder neuer wird der Bug behoben
• Nutzer können über den Befehl apt update && apt upgrade ein manuelles Paket-Update durchführen
  • Bis die automatische Update-Funktion wiederhergestellt ist, werden regelmäßige manuelle Prüfungen empfohlen

Bedeutung und Ausblick

• Der Vorfall gilt als Beispiel für anfängliche Instabilität im Verlauf der Rust-Migration
  • Er zeigt, dass die Einführung von Rust zur Verbesserung von Speichersicherheit und Sicherheit von einer Prüfung der funktionalen Stabilität begleitet werden muss
• Ubuntus Experiment könnte die Einführung von Rust in Linux-Distributionen insgesamt beschleunigen
• Falls Rust-basierte Utilities in künftigen LTS-Releases stabil integriert werden, sind Verbesserungen bei Systemsicherheit und Wartungseffizienz zu erwarten

[GN⁺]

Hacker-News-Kommentare

• Ich finde es in Ordnung, Probleme früh zu entdecken
  Solange das vor der LTS-Veröffentlichung bereinigt wird, ist es kein Problem

  • Als normaler Ubuntu-Nutzer bin ich mir nicht sicher, ob das wirklich okay ist
    Wenn man sich das Test-Kompatibilitätsdiagramm von uutils/coreutils ansieht, ist das noch nicht vollständig
    Vor allem date besteht nur 2 Tests, 3 werden übersprungen und 3 schlagen fehl
    In diesem Zustand würde ich das nicht als produktionsreif ansehen
  • Wenn man mehrere Systeme betreibt, vertraut man manchen Komponenten so sehr, dass man sie bei Problemen gar nicht erst verdächtigt
    Solche Bugs mögen für einzelne Nutzer trivial sein, in großen Umgebungen sind sie aber fatal
    Ich habe heute den ganzen Tag debuggt und am Ende festgestellt, dass ein System Daten an einen ausdrücklich verbotenen Ort geschickt hat
    Dadurch stand am Ende das gesamte System still, und wenn ein Werkzeug kaputtgeht, von dem alles abhängt, wird die Verwaltung wirklich schwierig
    Wäre das in einer anderen Sprache als Rust passiert, hätten die Entwickler gewaltige Kritik bekommen
  • Wenn zentrale Utilities ohne klaren Grund durch eine neu geschriebene Version ersetzt werden und diese so instabil ist, dass eine stabile Distribution sich nicht einmal sauber aktualisieren kann, kann man kaum sagen, dass das in Ordnung ist
  • „So findet man Issues nun mal“ klingt ein bisschen nach einer typischen Microsoft-Reaktion /s

• Ich frage mich, ob es beim bestehenden coreutils wirklich Probleme gab, die groß genug für Verbesserungen waren

  • Wahrscheinlich könnte es an Lizenzfragen liegen. Diese Vermutung gab es schon einmal in diesem Kommentar
  • Aus Sicht eines OpenBSD-Maintainers gehört es dazu, coreutils in einer Sprache zu implementieren, wenn man beurteilen will, ob sie als Systemsprache geeignet ist
    Dazu passend: OpenBSD-Mailingliste
  • Es könnte auch an Sicherheitsproblemen wie CVE-2015-4042 liegen
  • Das Problem scheint gewesen zu sein, dass es nicht in Rust geschrieben war. Ich frage mich allerdings, warum der Borrow Checker den date-Bug nicht erkannt hat
  • Wer den Hintergrund verstehen möchte, sollte den offiziellen Ubuntu-Beitrag Carefully but purposefully oxidising Ubuntu lesen

• Ich würde gern den Link zum Patch in uutils finden

  • Im LWN-Artikel wird das erklärt
    Der eigentliche Bug war, dass die Unterstützung für date -r <file> nicht implementiert war, Ubuntu diese Version aber integriert hat
    Der Befehl hat die Option -r stillschweigend ignoriert und einfach nichts getan
    Zugehörige Tickets: #8621, PR #8630
  • Der Ubuntu-Bugreport ist hier
  • Ich denke, die Wurzel des Problems ist schon die Existenz dieses Rust-Rewrite-Projekts selbst
  • Schade ist, dass die konkrete Problembeschreibung etwas dünn ist
    Der letzte Commit (Link) war eine Anpassung, damit das date-Parsing zu GNU passt, aber anderen Kommentaren nach war das vielleicht gar nicht die Ursache

• Der Top-Kommentar war witzig — der nächste Ubuntu-Release werde wohl Grateful Guinea-Pig heißen

• Im Ubuntu-Changelog sieht man, dass der Bug mit date -r zusammenhängt
  Wenn man das Changelog, den Bugreport, das Issue und den PR ansieht,
  sollte date -r die Änderungszeit einer Datei ausgeben, aber die Rust-Version hat es einfach ignoriert
  So ein fehlendes Grundverhalten ist enttäuschend für ein Projekt, das sich als „sicherer Ersatz“ präsentiert

  • Wenn diese Version tatsächlich die offiziellen Tests von coreutils bestanden hat, könnte das eher bedeuten, dass die Testsuite unvollständig ist
  • Aber immerhin gab es keinen Buffer Overflow!

• Die Ubuntu-Sicherheitsmitteilung — wirkt wie ein typischer Fall

• Ubuntu 25.10 fühlte sich für mich praktisch unbenutzbar an. Das habe ich über eine Nicht-LTS-Version noch nie gesagt

  • Mich würde interessieren, was genau so gravierend war

• Ich stimme der Aussage zu: „Das Umschreiben jahrzehntelang erprobter C-Utilities in Rust kann langfristig gut sein, aber die kurzfristigen Probleme waren vorhersehbar“
  Allerdings frage ich mich, wie lang „langfristig“ hier eigentlich sein soll
  Bei einem FOSDEM-Vortrag behauptete ein uutils-Entwickler anhand fehlerhafter Benchmarks, die Performance sei besser, obwohl der eigentliche Grund die fehlende Locale-Unterstützung war
  Dazu: FOSDEM-Vortrag, Thread1, Thread2

  • Andererseits sind auch diese zentralen Tools letztlich das Ergebnis mehrfacher Rewrites. Man sollte das nicht zu extrem sehen
  • Nachdem die Locale-Behandlung hinzugefügt wurde, soll sich die Performance sogar verbessert haben; dazu gibt es auch einen Phoronix-Artikel
  • Statt solcher Rewrites hätte man mit derselben Mühe vielleicht besser ein System für formale Verifikation aufbauen können
  • Es kommt auch vor, dass Open-Source-Projekte zum Aufbau persönlicher Reputation genutzt werden
    Zentrale Utilities neu zu schreiben ist schließlich ein großer Pluspunkt im Portfolio

• Mich interessieren guided state-space exploration oder der Stand der Technik beim Fuzzing
  Wenn es bereits eine bestehende Implementierung gibt, könnte ein Fuzzer das Verhalten beider Versionen vergleichen und so eine Whitebox-Verifikation durchführen

  • Dafür scheint Property Testing gut geeignet zu sein
    Es ist zwar mit viel Aufwand verbunden, proptest über den gesamten Eingaberaum zu schreiben, aber wenn die CLI-Argumente stabil sind, sollte das machbar sein
    Vielleicht ließe sich das sogar auf Basis von Materialien wie Manpages automatisch erzeugen
    Unter Rust würde sich das Crate proptest anbieten, und für die Verifikation von CLI-Unterschieden per externem Aufruf wäre Hypothesis in Python wohl sinnvoll