Verpflichtende Rust-Abhängigkeiten sollen ab Mai 2026 in Debian APT eingeführt werden

• Im APT-Paketmanager von Debian sollen ab Mai 2026 Rust-basierter Code und Abhängigkeiten enthalten sein
• In der ersten Phase sollen der Rust-Compiler, die Standardbibliothek und das Sequoia-Ökosystem integriert werden
• Parser für .deb-, .ar- und .tar-Dateien sowie HTTP-Signaturprüfcode gelten im Hinblick auf Speichersicherheit und verstärkte Unit-Tests als wichtigste Verbesserungsbereiche
• Ports ohne Rust-Toolchain müssen innerhalb von 6 Monaten eine Rust-Umgebung aufbauen oder werden eingestellt (sunset)
• Das ist eine Maßnahme, um das gesamte Projekt auf moderne Werkzeuge und Technologien umzustellen, ohne durch die Kompatibilität mit alter Hardware ausgebremst zu werden

---

Geplante Einführung von Rust-Code in APT

• Für APT ist die Einführung von Rust-Code und harten Abhängigkeiten (hard dependencies) nach Mai 2026 vorgesehen
  • Der Einführungszeitpunkt liegt nach Mai 2026; davor wird dies nicht umgesetzt
• Der Umfang der ersten Integration ist auf den Rust-Compiler, die Standardbibliothek und das Sequoia-Ökosystem begrenzt

Ziel: bessere Codequalität und Sicherheit

• Der Parsing-Code für .deb-, .ar- und .tar-Dateien sowie der HTTP-Signaturprüfcode sind die wichtigsten Zielbereiche für die Rust-Einführung
  • Es wird ausdrücklich darauf hingewiesen, dass diese Bereiche stark von den Vorteilen einer speichersicheren Sprache und eines verstärkten Unit-Test-Systems profitieren werden

Anforderungen an Port-Maintainer

• Ports ohne Rust-Toolchain müssen innerhalb von 6 Monaten eine Rust-Umgebung aufbauen
  • Andernfalls kann der betreffende Port eingestellt (sunset) werden

Projektausrichtung

• Es wird betont, dass sich das Debian-Projekt mithilfe moderner Werkzeuge und Technologien weiterentwickeln muss
  • Es wird ausdrücklich gesagt, dass die Weiterentwicklung nicht dadurch verzögert werden darf, dass man sich an alter Hardware oder Retro-Computing-Geräten orientiert

Weitere Informationen

• Der Absender ist der Debian- und Ubuntu-Core-Entwickler Julian Andres Klode
• Die Mail wurde auf der Debian-Entwickler-Mailingliste debian-devel veröffentlicht
• Als Anhang ist eine PGP-Signatur (signature.asc) enthalten
• Es gibt keine zusätzlichen Angaben zu technischen Details oder Änderungen am Zeitplan

[GN⁺]

Hacker-News-Kommentare

• Es scheint, als sei die Zeit dafür endlich gekommen. Code zum Parsen nicht vertrauenswürdiger Daten weiterhin in C zu belassen, ist eine technische Schuld, die mit der Zeit nur größer wird
  Rust ist nicht viel schwerer zu schreiben als C und wirkt wie die Sprache, die herauskäme, wenn man C heute unter Berücksichtigung des aktuellen Wissens über Sprachdesign und Codesicherheit neu entwickeln würde
  Wenn man die Unterstützung für 32-Bit-x86 aus praktischen Gründen aufgeben kann, dann gilt das ebenso für diese Architekturen. Wenn man sie wirklich erhalten will, muss man eben selbst ein Rust-Toolchain-Backend bauen

  • Derzeit sind im Basissystem für Kernanwendungen im Wesentlichen C, C++, Shell (bash), Perl und Python zugelassen. Python kam vor etwa 20 Jahren hinzu, und Rust ist die erste Sprache, die nah genug dran ist, um die Rolle von C zu ersetzen
    Go kam dem noch am nächsten, wurde aber nie ernsthaft für Kernsysteme wie systemd diskutiert. Ich frage mich, ob es damals bei der Aufnahme von C++, Python und Perl ähnliche Debatten gab
  • Es heißt, „Parser für .deb, .ar, .tar und Code zur HTTP-Signaturprüfung würden von einer speichersicheren Sprache profitieren“, aber ich frage mich, welchen konkreten Nutzen es bringt, über 30 Jahre gereiften Code extra in einer neuen Sprache neu zu schreiben
    Lohnt es sich wirklich, bereits kampferprobten Code aufzugeben und dafür neue Kompatibilitätsprobleme und Bugs zu erzeugen?
  • Als praktischerer Ansatz zur Behebung von Sicherheitsproblemen in altem C-Code gibt es das Fil-C-Projekt. Es macht C faktisch zu einer verwalteten Sprache und reduziert so den Bedarf an Neuschreibungen
  • Es geht nicht nur um Speichersicherheit. Wegen der Überalterung der C-Community wird es schwer, Leute für die Wartung zu finden. Auch unser Team migriert den gesamten C/C++-Code in andere Sprachen. Die meisten C/C++-Entwickler sind um die 40 und wenig wechselwillig
  • Ich kann der Behauptung schwer zustimmen, Rust sei eine moderne Neuerfindung von C. Zum Beispiel ist der Code des Uhren-Widgets im COSMIC-Desktop deutlich schwerer lesbar als C-Code mit vergleichbarer Komplexität, etwa in GNU coreutils

• Der Trend, Kernsysteme in Rust neu zu schreiben, ist stark, aber ich bezweifle, dass das die Sicherheit tatsächlich verbessert, wenn man alte Werkzeuge einfach neu implementiert
  Ich verstehe, dass es schwierig ist, neue Systeme einzuführen, aber es fühlt sich immer noch so an, als würde man Schicht um Schicht auf Entscheidungen aus der Telegraphenzeit stapeln

  • Für solche Neuschreibungen hört man zwei Gründe.
    Erstens gibt es kaum neue Mitwirkende, die sich mit alten C/C++-Codebasen befassen wollen. Eine Migration nach Rust erleichtert den Zustrom neuer Entwickler
    Zweitens wird Zuverlässigkeit durch häufige Nutzung geprüft, Sicherheit dagegen nur durch Angriffe. Man kann nicht davon ausgehen, dass alter Code bereits alle Angriffsvektoren durchlaufen hat. Deshalb ist das Argument für proaktive Sicherheitsverbesserungen stark
  • uutils/coreutils steht unter der MIT-Lizenz, GNU coreutils unter der GPL, also gibt es einen Lizenzunterschied. Für Unternehmen könnte das ein wichtiger Punkt sein
  • Irgendwer muss es lernen, deshalb finde ich es in Ordnung, einfache und gut testbare Projekte zu Übungszwecken neu zu schreiben. Ob das Ergebnis dann das Original ersetzen sollte, ist aber eine andere Frage

• Laut dem Debian-Mail-Thread ist Rust bereits auf den meisten Debian-Release-Architekturen Pflicht
  In der zugehörigen Mail werden nur alpha, hppa, m68k und sh4 als Ausnahmen genannt. Ich frage mich, was die Zukunft dieser Architekturen ist

  • Ich frage mich ehrlich, ob überhaupt noch jemand solche alten Maschinen nutzt. Die meiste Hardware ist über 20 Jahre alt.
    Rust bietet für m68k ein Tier-3-Ziel, aber nicht für die anderen Architekturen. Mich würden reale Anwendungsfälle interessieren
  • Laut Debian Supported Architectures haben diese Plattformen ohnehin keinen offiziellen Status.
    Dass sie geblieben sind, während 32-Bit-x86 und MIPS herausgefallen sind, überrascht mich. Ich habe persönlich etwas Nostalgie dafür, kenne aber keinen echten Einsatzzweck
  • Für m68k gibt es bereits einen LLVM-Port, daher ist eine Rust-Implementierung möglich. LLVM-Backends für alpha, hppa und sh4 hätten auch als Lehrmaterial einen gewissen Wert
    Früher gab es in LLVM einmal ein DEC-Alpha-Backend, aber das ist lange her
  • Aus Sicht von Ubuntu haben solche Architekturen keinen kommerziellen Wert
  • Sie sind komplett veraltet; man kann einfach bei der letzten unterstützten Version bleiben oder eine eigene Distribution bauen. Rust-Unterstützung hinzuzufügen ist unrealistisch

• Ich wünschte, die Rust-Community würde nicht in bestehende Projekte eindringen, sondern selbst neue moderne Technik bauen und damit den Beweis antreten
  Unabhängige Projekte wie Redox sind dafür ein Beispiel, und ich bedaure, dass solche Versuche nicht stärker vorangetrieben werden

  • Das ist eine offizielle Entscheidung von Debian, Rust-Abhängigkeiten hinzuzufügen. Das wurde nicht von externen Rust-Fans aufgezwungen
    Natürlich gibt es auch radikale Fans, die ständig „Schreibt es in Rust neu“ sagen, aber das ist hier nicht der Fall
  • ripgrep ist genau so ein Beispiel. Es wurde neu gebaut, und die Leute mögen es tatsächlich

• Die Rust-Standardbibliothek zu verwenden ist okay, aber ich will nicht für den Build eines simplen deb-Parsers 500 Cargo-Pakete mitschleppen

• Es könnte vernünftig sein, zu warten, bis der Rust-for-GCC-Port stabil ist
  Auch der Kernel wird Rust nicht verpflichtend machen, bevor es GCC-Unterstützung gibt.
  Mehrere Implementierungen würden die Sprache weniger instabil machen
  Wenn man die Architekturunterstützung aber jetzt kappt, könnte das spätere Zurückkehren kompliziert machen, falls es später doch eine Rust-Toolchain gibt

  • Tatsächlich sind diese Architekturen schon seit über 10 Jahren aus Debian herausgefallen. Durch diese Änderung fallen sie nicht neu weg
  • Es gibt keinen offiziellen Support, und sie werden nur von Einzelpersonen in ihrer Freizeit gepflegt. Ohne ein Unternehmen, das langfristige Wartung übernimmt, ist eine Rückkehr schwierig
  • GCCRS kann derzeit nicht einmal libcore bauen und liegt ungefähr auf dem Stand von Rust 1.50. Als allgemein nutzbarer Compiler wird das wohl noch Jahre dauern
    Wahrscheinlicher ist eher, dass rustc_codegen_gcc vorher stabil wird
  • Die Ports sind nicht Teil offizieller Debian-Releases und werden nur über den unstable-Kanal verteilt

• Ich erinnere daran, dass der Autor der Debian-Rust-Diskussionsmail der Paketbetreuer von keepassxc ist
  Es gibt Threads darüber, dass er sich auch früher gegenüber Upstream-Entwicklern und Nutzern grob verhalten hat

  • Ich habe das nach der Mail auch sofort nachgesehen und musste lachen, weil ich mich an frühere Threads erinnert habe
  • Ehrlich gesagt ist seine Wortwahl rau, aber direkt und nicht beleidigend. Das wirkt auf mich wie unnötiges Drama
  • Der HN-Beitrag selbst ist nicht aggressiv, aber manche scheinen ihn übertrieben aufzufassen
  • Solche Kultur ist in der Welt freier Software weit verbreitet. Seit GNOME 3 und Mozilla gibt es aus meiner Sicht die Tendenz, eher einem idealisierten Nutzertyp als echten Nutzern hinterherzulaufen

• Es ist interessant zu beobachten, wie sich die Meinung einer Person verändert. Link zur früheren Aussage

  • Es ist gut zu sehen, wenn jemand seine Ansichten mit der Zeit ändert
  • Auch die Einführung von Rust in APT könnte wie die Umstellung bei coreutils eher eine administrative Entscheidung sein

• Ich halte Rust für bloßen Hype. In der Embedded-Welt ist C immer noch König.
  Ich habe in meinem Umfeld noch nie jemanden gesehen, der Rust tatsächlich nutzt oder auch nur ernsthaft erwägt

  • Aus „in meinem Umfeld gibt es das nicht“ kann man schwer ein allgemeines Fazit ziehen. Es gibt viele Embedded-Entwickler, die Rust nutzen
  • Innerhalb von AWS werden Kerndienste wie EC2, IAM, DynamoDB und S3 in Rust geschrieben.
    Die Entwicklung ist schnell, während Leistung und Speichereffizienz erhalten bleiben.
    Der einzige Nachteil ist die Binärgröße. Ich denke, die Zukunft von Rust steht bereits fest
  • Rust ist auch im Embedded-Bereich stark, aber wegen mangelnder Herstellerunterstützung ist der anfängliche Aufwand pro Hardwareplattform hoch.
    Dennoch ist nicht nur die Speichersicherheit attraktiv, sondern die Gesamtqualität von Sprache und Toolchain
  • Mit avr-rust, esp-rs, cortex-m usw. verändert sich das Embedded-Ökosystem allmählich ebenfalls
  • Auch bei Microsoft, Google und anderen wird Rust diskutiert und bereits in echten Produkten eingesetzt

• Ich denke, eine polyglotte Umgebung schafft nur noch mehr Probleme.
  Python, Node, Go, Rust und so weiter benötigen jeweils eigene Toolchains und Paketmanager, was alles komplizierter macht
  Mit Node hat man zwar Buffer Overflows reduziert, dafür aber Supply-Chain-Angriffe vermehrt.
  Es wäre besser, gleich ganz neu anzufangen, und wenn man umfassend auf Rust setzen will, sollte man lieber zu Redox OS beitragen

  • Realistisch betrachtet hat jede Sprache eigene Vor- und Nachteile, und Debian muss als praktisches Betriebssystem verschiedene Sprachen unterstützen
    Alles in einer Sprache neu zu schreiben ist unrealistisch, und Redox zu pushen könnte sogar ineffizient sein
    Rust ist bereits ausreichend erprobt und hat als kompilierte Sprache mit geringerer Selbstzerstörungsgefahr bei Änderungen gegenüber C einen klaren Wert
    Auch das Aufgeben alter Architekturen ist nicht unvernünftig
  • Für ein großes Projekt wie Debian ist es vernünftig, die Auswahlmöglichkeiten zu erweitern. Rust hinzuzufügen ist eine nachvollziehbare Entscheidung
    Welche Sprachen entfernt oder aufgenommen werden, sollten die Debian-Betreuer entscheiden
  • Linux hat den Kampf gegen die Komplexität schon vor Jahrzehnten aufgegeben