Canonical schreibt Ubuntu nicht vollständig in Rust neu, hat jedoch damit begonnen, zentrale Systemkomponenten an Stellen zu ersetzen, an denen die Vorteile bei Speichersicherheit und Wartung ihrer Ansicht nach die Übergangskosten rechtfertigen. Wie Jon Seager, Vizepräsident für Engineering bei Canonical, während einer von JetBrains veranstalteten Sendung erläuterte, ist die Entscheidung Teil einer langfristigen Vision für eine Plattform, auf der rund 15 Millionen Bereitstellungen auf Servern, Desktop- und Edge-Geräten sowie in Fahrzeugen ausgeführt werden.
Der Ansatz geht von der Frage aus, was Ubuntu in den nächsten zwei Jahrzehnten benötigt, und nicht von einer Kampagne, jedes vorhandene Werkzeug neu zu implementieren. Canonical ist der Ansicht, dass Rust ein überzeugendes Werkzeugset für die Systementwicklung bietet, insbesondere wenn die Vermeidung von Speicherfehlern und die Zuverlässigkeit wichtige Faktoren bei Software sind, die in Industriesystemen, Fahrzeugen oder kritischen Infrastrukturen läuft.
Selektive Ersetzungen statt einer vollständigen Neuentwicklung
Die ersten dieser Komponenten erreichten Ubuntu 26.04 LTS. uutils coreutils, eine in Rust geschriebene Neuimplementierung der GNU coreutils, wurde zur Standardoption, mit dem erklärten Ziel, vollständige Kompatibilität mit dem Verhalten der GNU-Werkzeuge zu erreichen. Das bedeutet, dass eine kleine Verhaltensabweichung nicht unbedingt als Verbesserung betrachtet wird, sondern als Fehler gelten kann, wenn sie ein Skript oder ein Werkzeug beschädigt, das vom bisherigen Verhalten abhängt.
sudo-rs verfolgt dagegen einen anderen Weg. Statt vollständige Übereinstimmung mit sudo anzustreben, überdenkt das Projekt, wie ein Werkzeug zur Rechtevergabe aussehen würde, wenn es heute nach Jahrzehnten sicherheitstechnischer Erfahrung entwickelt würde. Zu den Änderungen, die starke Reaktionen ausgelöst haben, gehört die standardmäßige Anzeige von Sternchen bei der Eingabe des Passworts im Terminal. Canonical erklärt, dass sie diese beabsichtigten Änderungen auch dann akzeptiert, wenn sie kurzfristig Reibung verursachen, da sie Teil eines neuen Designs und nicht bloß einer kompatiblen Ersatzversion seien.
Zeit und Zertifikate im Änderungsumfang
Das nächste Projekt ist ntpd-rs, dessen Finanzierung Canonical im Juni 2026 über die Trifecta Tech Foundation angekündigt hat, mit dem Ziel, es zum standardmäßigen Werkzeug für die Zeitsynchronisierung in Ubuntu zu machen. Der Plan sieht vor, es in Ubuntu 26.10 zu archivieren und anschließend in Ubuntu 28.04 vollständig zur Standardoption zu machen, sodass es chrony und linuxptp schrittweise durch ein einzelnes Werkzeug ersetzt, das NTP, NTS und PTP unterstützt.
Die Bedeutung dieser Änderung ergibt sich daraus, dass präzise Zeitsynchronisierung nicht auf Netzwerkserver beschränkt ist. Sie betrifft Mikrocontroller in Flugzeugen, Fahrzeugen und Robotern, kryptografische Systeme, die Schlüssel regelmäßig rotieren, sowie systeme, die vom Standort abhängen. Der Artikel erklärt, dass die gemeinsame Verwendung von chrony und linuxptp die Einrichtung mehrerer Werkzeuge und Zeitquellen erfordern kann, während ntpd-rs darauf abzielt, diese Funktionen in einem einzigen Werkzeug und einer einzigen Konfigurationsdatei zu bündeln und dabei die Speichersicherheit zu nutzen.
UPKI unterscheidet sich von diesen Ersetzungen, da es in Zusammenarbeit mit dem Rustls-Projekt von Grund auf neu entwickelt wird und die Überprüfung des Zertifikatswiderrufs zu Systemwerkzeugen unter Linux hinzufügen soll. Canonical strebt die erste Aufnahme in Ubuntu 26.10 an. Die Idee steht im Zusammenhang mit Werkzeugen wie curl, wget und OpenSSL, bei denen diese Art der Behandlung von Zertifikatswiderrufen laut dem Artikel nicht auf dieselbe Weise integriert ist wie in Browsern.
Was ändert sich praktisch für die Nutzer?
Canonical hat für die Einführung dieser Änderungen die Grenzen der LTS-Versionen gewählt, weil Organisationen ihre Systeme üblicherweise an diesen Punkten aktualisieren und weil ein Rückfallpfad bei der Änderung von Werkzeugen auf niedriger Systemebene wichtig ist. Dem Artikel zufolge erhalten frühere Versionen 15 Jahre lang verwalteten Support, und die älteren Werkzeuge bleiben im Archiv erhalten, sodass das neue Verhalten einem bestehenden Produktionssystem nicht ohne Rückkehrmöglichkeit aufgezwungen wird.
Die Kompatibilität ist jedoch zwischen den Projekten nicht einheitlich. uutils coreutils stieß auf ein praktisches Beispiel, als das Werkzeug head einen Fehler zurückgab, wenn die Ausgabe einer bestimmten Anzahl von Bytes aus einer leeren Datei angefordert wurde, während GNU coreutils null zurückgab. Diese Abweichung führte dazu, dass ein in das Obsidian-Snap-Paket eingebettetes Skript beschädigt wurde; daraufhin wurde das Verhalten angepasst, damit es mit GNU übereinstimmt. Das Beispiel zeigt, dass Speichersicherheit nicht die Bedeutung der Kompatibilität mit Annahmen beseitigt, die sich über 30 Jahre hinweg rund um die alten Werkzeuge angesammelt haben.
Die Herausforderung endet nicht beim Schreiben des Codes
Die Einführung von Rust in eine große Distribution erfordert auch die Bearbeitung der Kette aus Abhängigkeiten, Build und Distribution. Canonical bündelt die Crates jedes Pakets in einem einzigen Archiv, statt jedes Crate als separates deb-Paket zu verpacken. Dem Artikel zufolge trägt dies dazu bei, die Abhängigkeitsoberfläche verwaltbar zu halten und die Builds deterministisch zu machen, auch wenn sie im formalen Sinn nicht reproduzierbar sind.
Anfang 2026 wurde cargo auditable auf alle Rust-Pakete im Ubuntu-Archiv ausgeweitet. Jede Rust-Binärdatei enthält eine eingebettete SBOM, in der die beim Build verwendeten Namen und Versionen der Crates erfasst werden und die bei einer erneuten Erstellung des Pakets automatisch aktualisiert wird. Diese Daten verhindern keine Schwachstellen, machen jedoch die Ermittlung betroffener Versionen bei der Entdeckung eines Problems in einer der Abhängigkeiten direkter.
Einordnung von certi.news: Bei der tatsächlichen Veränderung geht es hier nicht nur darum, in C geschriebene Werkzeuge durch solche in Rust zu ersetzen, sondern eine Ebene für Sicherheit, Wartung und Abhängigkeitsverfolgung in Komponenten einzuführen, die nach ihrer Verbreitung nur schwer zu ändern sind. Gleichzeitig zeigen die Beispiele zur Kompatibilität und das Verhalten von sudo-rs, dass der Übergang Designentscheidungen erzwingen kann, die Nutzer bemerken, und dass sein Erfolg ebenso von der Verwaltung dieser Unterschiede wie von der verwendeten Programmiersprache abhängen wird. Die angekündigten Zeitpläne für ntpd-rs und UPKI bleiben künftige Ziele, während die Quelle belegt, dass der Änderungsumfang selektiv ist und ältere Werkzeuge sowie Rückfalloptionen weiterhin Teil der Strategie von Canonical sind.