Ubuntu 26.10 schließt Umstieg auf Rust-Coreutils ab: cp, mv und rm kommen von uutils

Die offiziellen Release Notes zu Ubuntu 26.10 mit dem Codenamen Stonking Stingray führen seit dem 11. September 2026 einen Abschnitt mit der Überschrift "100% Rust coreutils". Darin steht, dass die Standard-Kernwerkzeuge des Systems vollständig auf der Rust-Implementierung uutils laufen und dass die zuvor aus Kompatibilitätsgründen zurückgehaltenen GNU-Werkzeuge cp, mv und rm nun ebenfalls migriert sind. Fachmedien haben die Änderung am 17. September 2026 aufgegriffen. Ubuntu 26.10 ist noch in Entwicklung, der geplante Erscheinungstermin ist der 15. Oktober 2026.

Handlungsbedarf für heute besteht nicht. Wer Ubuntu 24.04 LTS oder Debian betreibt, ist von der Änderung gar nicht betroffen. Wer Ubuntu 26.04 LTS einsetzt, nutzt bereits überwiegend uutils, bekommt cp, mv und rm aber weiterhin von GNU. Relevant wird das Thema für alle, die ein Upgrade auf 26.10 planen oder deren Testsysteme ohnehin auf dem Entwicklungszweig laufen. Für diese Gruppe lohnt sich jetzt ein strukturierter Skript-Test, weil Ubuntu 26.10 ein Zwischenrelease mit nur neun Monaten Support ist und damit als Vorschau auf das nächste LTS dient.

Was ist passiert?

Canonical hatte den Umstieg auf Rust-basierte Kernwerkzeuge im Frühjahr 2025 angekündigt und mit Ubuntu 25.10 erstmals als Standard ausgeliefert. Die Coreutils bündeln elementare Unix-Kommandos für Datei-, Text- und Shell-Operationen, darunter ls, cat, chmod, du, cp, mv und rm. Die verbreitete Implementierung stammt von GNU und ist überwiegend in C geschrieben. uutils ist eine eigenständige Neuimplementierung derselben Kommandos in Rust.

Für Ubuntu 26.04 LTS blieb die Migration bewusst unvollständig. In einem Beitrag vom 22. April 2026 hat das Ubuntu-Foundations-Team offen dargelegt, warum: Bei cp, mv und rm waren zu diesem Zeitpunkt noch acht TOCTOU-Probleme offen. TOCTOU steht für Time of Check to Time of Use und beschreibt eine Lücke zwischen einer Prüfung und der anschließenden Aktion, in der sich ein Pfad oder ein symbolischer Link ändern kann. Weil diese drei Kommandos Verzeichnisbäume rekursiv kopieren, verschieben und löschen, wurde diese Klasse von Problemen als zu kritisch für ein LTS bewertet. Ubuntu 26.04 LTS lieferte deshalb uutils in Version 0.8.0 aus und behielt die GNU-Varianten für die drei Werkzeuge.

Parallel dazu hat Canonical das Projekt extern prüfen lassen. Die Sicherheitsfirma Zellic hat uutils in zwei Runden auditiert, Runde eins von Dezember 2025 bis Januar 2026 für die sicherheitskritischen Werkzeuge, Runde zwei von Februar bis März 2026 für den Rest. Über beide Runden wurden nach Angaben des Ubuntu-Teams 113 Befunde unterschiedlicher Schwere gefunden, aufgeteilt in 73 und 40. Der Großteil wurde upstream behoben. Canonical hat dazu 44 CVE-Einträge offengelegt, durchnummeriert von CVE-2026-35338 bis CVE-2026-35381.

Das uutils-Projekt selbst hat am 17. September 2026 die Version 0.12.0 veröffentlicht. Die Release Notes bezeichnen den Zyklus ausdrücklich als Kompatibilitätsrelease für Ubuntu und nennen als Stand der GNU-Testsuite 653 bestandene und 21 fehlgeschlagene Tests bei 692 Tests insgesamt. Das Repository unter github.com/uutils/coreutils steht unter MIT-Lizenz und zählte beim Abruf am 18. September 2026 rund 24.100 Sterne bei 2.035 Forks; der letzte Push war der 17. September 2026.

Für wen ist das relevant?

Entscheidend ist die eingesetzte Ubuntu-Version. Die folgende Übersicht fasst den Stand der Standard-Coreutils je Release zusammen.

Ubuntu-Version	Standard-Coreutils	cp, mv, rm
22.04 LTS, 24.04 LTS	GNU coreutils	GNU
25.10 (Questing Quokka)	uutils als neuer Standard	GNU
26.04 LTS (Resolute Raccoon)	uutils 0.8.0	GNU
26.10 (Stonking Stingray, in Entwicklung)	uutils vollständig	uutils

Nicht betroffen sind Debian-Systeme, andere Distributionen und sämtliche Ubuntu-LTS-Installationen bis einschließlich 24.04. Ebenfalls nicht betroffen ist der Rest des Systems: Die Änderung ersetzt nicht das gesamte Userland durch Rust. Linux-Kernel, Shell und systemnahe Dienste bleiben unverändert, und das Projekt GNU coreutils besteht als Software weiter. GNU coreutils 9.12 ist während des uutils-Zyklus erschienen.

Praktisch relevant ist das Thema damit vor allem für diese Gruppen:

• Betreiber von Ubuntu-Servern, die ein Upgrade auf 26.10 planen oder auf dem Entwicklungszweig testen.
• Teams mit umfangreichen Shell-Skripten, Backup-Jobs oder CI-Pipelines, die Coreutils-Ausgaben weiterverarbeiten.
• Admins, die Container-Images auf Ubuntu-Basis bauen und auf Image-Größe achten.
• Umgebungen mit AppArmor-Profilen, die einzelne Coreutils-Binaries adressieren.
• Alle, die schon jetzt auf 26.04 LTS wissen wollen, wie sich ihre Skripte in der nächsten LTS-Generation verhalten werden.

Wie kritisch ist das?

Das ist keine Sicherheitsmeldung und kein Vorfall. Es gibt keine aktiv ausgenutzte Schwachstelle, keinen Notfallpatch und keinen Grund, heute Wartungsfenster zu öffnen. Die 44 offengelegten CVEs stammen aus dem Audit und sind nach Angaben des Ubuntu-Teams weitestgehend upstream behoben, sie beschreiben also den Weg zur jetzigen Freigabe und keine offene Lage.

Das operative Risiko liegt woanders, nämlich in der Kompatibilität. uutils bildet die Befehlsnamen und Optionen der GNU-Coreutils nach, und Abweichungen gelten dem Projekt ausdrücklich als Fehler und nicht als gewollte Neuerung. Trotzdem ist die Übereinstimmung nicht bei hundert Prozent: 21 Tests der GNU-Testsuite schlagen in Version 0.12.0 weiterhin fehl. Wer ein Skript betreibt, das seit Jahren stabil läuft und auf eine bestimmte Ausgabeformatierung angewiesen ist, sollte vor dem Upgrade prüfen und nicht nach dem Upgrade debuggen.

Auch der Sicherheitsgewinn sollte nüchtern eingeordnet werden. Rust vermeidet Speicherfehler wie Use-after-free oder Pufferüberläufe. Vor Logikfehlern, falscher Rechtebehandlung oder Race Conditions schützt die Sprache nicht. Genau die TOCTOU-Probleme bei cp, mv und rm haben das gezeigt: Der Wechsel der Programmiersprache ersetzt die Prüfung der Semantik nicht.

Welche Verhaltensunterschiede sind bekannt?

Ein dokumentierter Fall aus dem Ubuntu-Forum betrifft date. Unter Ubuntu 24.04 mit GNU coreutils liefert date +%s%1N eine auf eine Nachkommastelle gekürzte Ausgabe, unter Ubuntu 26.04 mit uutils dagegen die volle Nanosekunden-Auflösung. Grund ist, dass uutils die Ziffernangabe im Formatmodifikator als Mindestbreite und nicht als feste Breite interpretiert. Skripte, die aus solchen Ausgaben feste Feldlängen erwarten, laufen danach mit deutlich längeren Zahlen weiter, ohne einen Fehler zu melden. Das ist die unangenehme Fehlerklasse, weil kein Exit-Code darauf hinweist.

Ein zweiter Unterschied betrifft die Dokumentation. Die von uutils mitgelieferten Manpages sind knapper als die GNU-Varianten und listen teilweise weniger Optionen auf. Wer im Betrieb Optionen anhand von man nachschlägt, sollte bei Zweifelsfällen zusätzlich --help und die Projektdokumentation heranziehen.

Weitere Punkte, die aus der Migrationsspezifikation und den Projektangaben stammen und die im Betrieb auffallen können:

• uutils wird als Multi-Call-Binary ausgeliefert, die einzelnen Kommandos sind Symlinks auf ein gemeinsames Binary. AppArmor-Profile folgen Symlinks und können damit nicht mehr zwischen einzelnen Werkzeugen unterscheiden.
• Die Binärgröße unterscheidet sich deutlich: In der Migrationsspezifikation wurden rund 25 MB für die Rust-Variante gegenüber rund 7 MB für die klassische Variante genannt, was Container-Images entsprechend wachsen lässt.
• --version meldet jetzt "uutils coreutils" statt "GNU coreutils". Skripte, die diese Ausgabe parsen, brauchen eine Anpassung.
• Pakete mit einer versionierten Abhängigkeit auf coreutils wurden in der ursprünglichen Spezifikation als bekannter offener Punkt geführt.
• Fehlermeldungen und deren Wortlaut können abweichen. Skripte, die auf Meldungstexte statt auf Exit-Codes prüfen, sind hier besonders anfällig.

Was sollten Admins jetzt tun?

• Zuerst den Bestand prüfen: Welche Systeme laufen auf welcher Ubuntu-Version? Mit lsb_release -a die Version feststellen und mit ls --version beziehungsweise cp --version ermitteln, welche Implementierung tatsächlich aktiv ist.
• Danach entscheiden, ob 26.10 überhaupt eingeplant ist. Für Produktionsserver ist ein Zwischenrelease mit neun Monaten Support meist die falsche Wahl; dort bleibt 26.04 LTS der Referenzstand, und die Prüfung dient der Vorbereitung auf das nächste LTS.
• Skripte inventarisieren: Backup- und Rotationsjobs, Deployment-Skripte, Cron-Jobs, CI-Pipelines und Monitoring-Checks, die Coreutils-Ausgaben weiterverarbeiten, gehören auf eine Liste.
• Diese Skripte in einer Testumgebung gegen 26.10 laufen lassen, bevorzugt in einer VM oder einem Container, und Ausgaben mit dem bisherigen Stand vergleichen statt nur auf Exit-Codes zu schauen.
• Besonderes Augenmerk auf Stellen legen, die Ausgaben mit cut, awk oder festen Spaltenbreiten zerlegen, sowie auf Skripte, die Fehlermeldungstexte auswerten.
• AppArmor-Profile durchsehen, die einzelne Coreutils-Pfade freigeben, und prüfen, ob sie nach der Umstellung auf das Multi-Call-Binary noch die gewünschte Wirkung haben.
• Container-Images auf Ubuntu-Basis auf Größenänderungen prüfen, wenn Image-Größe ein Kriterium in der Registry oder im Deployment ist.
• Vor dem Upgrade ein geprüftes Backup anlegen und den Rückweg auf GNU coreutils vorab einmal in der Testumgebung durchspielen, damit er im Ernstfall bekannt ist.
• Auffälligkeiten melden statt umgehen: Canonical bittet ausdrücklich um Fehlerberichte über ubuntu-bug rust-coreutils beziehungsweise über den Issue-Tracker des uutils-Projekts.

Ein einfacher Vergleichstest lässt sich mit wenigen Zeilen aufbauen. Das Muster ist, die relevanten Kommandos auf beiden Implementierungen auszuführen und die Ausgaben zu differenzieren:

# Aktive Implementierung und Version feststellen
ls --version | head -n 1
cp --version | head -n 1

# Ausgabe der uutils-Variante sichern
date +%s%1N > /tmp/out_uutils.txt
du -sh /var/log >> /tmp/out_uutils.txt

# Gleiche Befehle mit der GNU-Variante, falls parallel installiert
gnudate +%s%1N > /tmp/out_gnu.txt
gnudu -sh /var/log >> /tmp/out_gnu.txt

# Unterschiede sichtbar machen
diff /tmp/out_uutils.txt /tmp/out_gnu.txt

Die GNU-Varianten sind im Paket mit einem gnu-Präfix abgelegt, also etwa gnuls, gnucp oder gnudate. Das ist der schnellste Weg, einen Unterschied zu isolieren, ohne das System umzustellen.

Wie der Rückweg auf GNU coreutils aussieht

Canonical hat den Wechsel von Anfang an umkehrbar ausgelegt. Weil die Coreutils unter Debian und Ubuntu zu den Essential-Paketen gehören und schon beim Entpacken anderer Pakete verfügbar sein müssen, kamen weder das Debian-Alternatives-System noch einfache Paketumleitungen infrage. Stattdessen gibt es ein leeres Metapaket coreutils und zwei austauschbare Anbieter: coreutils-from-uutils und coreutils-from-gnu. Genau ein Anbieter ist jeweils installiert.

Der dokumentierte Weg zurück sieht so aus:

# Variante 1: direkt ueber apt
sudo apt install coreutils-from-gnu coreutils-from-uutils- --allow-remove-essential

# Variante 2: ueber dpkg, wenn apt die Reihenfolge nicht sauber aufloest
apt download coreutils-from-gnu
sudo dpkg --install ./coreutils-from-gnu*.deb

Bei der zweiten Variante entfernt dpkg den bisherigen Anbieter selbst. Die Paketskripte arbeiten dabei mit Schutzumleitungen über dpkg-divert, damit während des Wechsels kein cp oder ls kurzzeitig fehlt. Das Kommando enthält bewusst --allow-remove-essential, weil hier ein als essenziell markiertes Paket ausgetauscht wird. Dieser Eingriff gehört in ein Wartungsfenster und auf ein System mit geprüftem Backup, nicht in einen laufenden Produktionsbetrieb ohne Rückfallebene. Das Ubuntu-Forum zeigt, dass Anwender diesen Weg bereits nach dem Upgrade auf 26.04 genutzt haben.

Lizenzwechsel von GPL zu MIT sachlich eingeordnet

Die GNU coreutils stehen unter der GPLv3 oder später, uutils steht laut Repository unter MIT-Lizenz. Für den normalen Serverbetrieb ändert das praktisch nichts: Beide Lizenzen erlauben Einsatz, Weitergabe und Veränderung, und in beiden Fällen ist der Quelltext öffentlich verfügbar. Ein Unternehmen, das Ubuntu betreibt und die Kommandos nutzt, hat aus keiner der beiden Lizenzen eine zusätzliche Pflicht.

Ein Unterschied entsteht erst bei der Weitergabe veränderter Software. Die GPL verlangt, dass Änderungen unter derselben Lizenz weitergegeben werden. Die MIT-Lizenz verlangt das nicht, sie fordert im Kern nur die Weitergabe des Lizenz- und Urheberrechtshinweises. Damit lässt sich uutils auch in proprietären Produkten einsetzen, was für Gerätehersteller und Appliance-Anbieter ein reales Argument ist und in der Community entsprechend kontrovers diskutiert wird. Für Admins und KMU, die Ubuntu einfach betreiben, ist dieser Punkt eine Einordnungsfrage und keine Compliance-Aufgabe. Wer eigene Distributionen, Images oder Appliances ausliefert, sollte die Lizenzangaben in der eigenen Stückliste trotzdem aktualisieren.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist die Meldung ein Planungsthema und kein Betriebsvorfall. Wer auf LTS setzt, was in der Regel die richtige Entscheidung ist, hat bis zum nächsten LTS Zeit. Sinnvoll ist es trotzdem, den Zeitpunkt jetzt zu nutzen, weil Ubuntu 26.10 genau dafür da ist: Zwischenreleases sind die Testfläche für das, was im nächsten LTS verbindlich wird. Eine Testinstallation mit den eigenen Skripten kostet wenige Stunden und verhindert, dass dieselbe Prüfung später unter Zeitdruck in einem LTS-Upgrade stattfindet.

Bemerkenswert ist der Umgang mit dem Vorgang selbst. Canonical hat die Migration nicht still durchgezogen, sondern ein externes Audit beauftragt, die Befunde offengelegt, die kritischen Werkzeuge zurückgehalten, bis die Probleme behoben waren, und den Rückweg technisch vorbereitet. Dass die Verantwortlichen für ein LTS bewusst bei GNU geblieben sind und die Umstellung ins Zwischenrelease verschoben haben, ist ein brauchbares Vorbild für die eigene Änderungsplanung: Ein Wechsel unterhalb gewohnter Kommandos braucht einen dokumentierten Rückweg, und der gehört vor dem Wechsel getestet.

Offen bleibt, wie sich die Kompatibilität in der Breite bewährt, wenn deutlich mehr Produktivsysteme auch cp, mv und rm aus Rust beziehen. Die 21 weiterhin fehlschlagenden Tests der GNU-Testsuite sind ein messbarer Rest, der im Alltag meist keine Rolle spielt, aber in einzelnen Skripten eben doch. Belastbare Praxisdaten dazu wird erst der Betrieb nach dem 15. Oktober 2026 liefern.

Passende Anleitungen auf S-EDV

• Pakete verwalten mit apt und dpkg unter Debian und Ubuntu: Grundlagen zu Paketanbietern, Abhängigkeiten und dpkg-Eingriffen, die beim Wechsel zwischen den Coreutils-Paketen gebraucht werden.
• Unattended Upgrades für automatische Sicherheitsupdates einrichten: Wie automatische Updates konfiguriert werden und welche Paketklassen dabei bewusst ausgenommen gehören.
• Linux-Server nach CIS-Benchmark härten: Systematische Härtung inklusive AppArmor und Dateirechten, die bei einem Wechsel der Coreutils-Implementierung mitgeprüft werden sollte.

Quellen

• Ubuntu 26.10 Release Notes, Abschnitt "100% Rust coreutils" (Primärquelle, Stand 11.09.2026, abgerufen 18.09.2026)
• Ubuntu Discourse: An update on rust-coreutils, 22.04.2026 (Audit, TOCTOU-Stand, CVE-Liste)
• Ubuntu Discourse: Migration to rust-coreutils in 25.10, 23.04.2025 (Paketmechanismus und Rückweg)
• uutils coreutils 0.12.0 Release Notes, 17.09.2026 (GNU-Testsuite-Stand)
• Repository uutils/coreutils auf GitHub (MIT-Lizenz, Stand der Kennzahlen per GitHub-API abgerufen am 18.09.2026)
• heise online: Ubuntu schließt Rust-Umstieg ab, 17.09.2026
• OMG! Ubuntu: Ubuntu 26.10 completes transition to Rust-based coreutils, September 2026