Bun-Rust-Neuschreibung: „Codebasis besteht grundlegende Miri-Prüfungen nicht und erlaubt UB in safe Rust“

• Dieses Issue ist derzeit Open; die Diskussion wurde als off topic gesperrt und auf Collaborators beschränkt, und als zugehörige Fixes sind #30728 und #30876 verknüpft
• Der Melder zeigt, dass ein mit PathString::init erzeugter Wert auch nach drop des ursprünglichen Box noch slice() aufrufen kann, wobei Miri Undefined Behavior auf Basis einer dangling reference meldet
• Der Reproduktionscode übergibt einen mit Box::new(*b"Hello World") erzeugten Puffer an PathString::init(&*test) und ruft nach drop(test) init.slice() auf; Miri meldet dabei einen Fehler an der Stelle core::slice::from_raw_parts
• robobun bestätigt, dass sich das Problem reproduzieren lässt, und fasst zusammen, dass PathString::init zwar eine safe Funktion ist, aber die slice lifetime auslöscht und dadurch ein dangling &[u8] erzeugen kann
• Das verknüpfte #30728 ändert PathString::init und die parallele Lücke in dir_iterator::next() zu unsafe fn und fügt an etwa 70 Aufrufstellen SAFETY-Kommentare hinzu, die die backing allocation explizit machen
• Dieselbe Änderung enthält laut Beschreibung auch einen compile_fail doctest, der bei drei Signaturen das Schlüsselwort unsafe erzwingt, sowie einen Fix für einen readdir-error-fd-leak im Resolver
• AwesomeQubic ergänzt, dass PathString::init außerdem die provenance auslöscht und auch mit MIRIFLAGS=-Zmiri-strict-provenance fehlschlägt
• JavaDerg erklärt, dass init die implizite Lifetime von &[u8] übernimmt, sie dann durch eine unsafe Operation auslöscht und Self zurückgibt, das wie 'static aussieht, wodurch use-after-free und invalid aliasing möglich werden
• JavaDerg warnt, dass UB im Sicherheitsmodell von Rust an unerwarteten Stellen Probleme verursachen kann, dass eine Überprüfung der allgemeinen unsafe-Nutzung nötig ist und dass sich Speichermanagement-Ansätze aus anderen Sprachen nicht 1:1 nach Rust übersetzen lassen
• robobun ergänzt als zugehörige Commits die Tests PathString::init signature stays unsafe und dir_iterator: make next() unsafe; audit call sites
• SimonReiff nennt als Ergebnis eines unsafe-grep in den Rust-Dateien des Repositories ohne Kommentare 13255 Zeilen und fordert, die Änderungen sofort zurückzunehmen sowie Richtlinien und Verfahren für den Einsatz von AI-Code zu diskutieren
• Jarred-Sumner erklärt, dass der Rust-Port derzeit von einem möglichst nahen 1:1 mapping des ursprünglichen Zig-Codes ausgeht und schrittweise verbessert wird, und bittet darum, Bugs oder unsound behavior im Rust-Code weiterhin in neuen Issues zu melden

[GN⁺]

Hacker-News-Kommentare

• Mein erstes Interesse an Bun kam daher, dass es in Zig geschrieben war, und Zig gefiel mir, weil ich Andrew Kelleys Entscheidungen und Geschmack vertraut habe.
  Auch die späteren Gründe, warum ich Bun immer interessanter fand, liefen letztlich darauf hinaus, dass es Entscheidungen waren, die ich respektieren konnte; selbst nach der Übernahme durch Anthropic wollte ich vorsichtig optimistisch bleiben.
  Aber dieser Schritt wirkt wie eine schwer vertrauenswürdige Entscheidung. Nicht weil Rust selbst das Problem wäre, sondern weil es sich schwer anfühlt, Bun noch als verlässlichen Bestandteil des Werkzeugkastens zu sehen, wenn Anthropic Bun auf diese Weise steuert.
  Man muss nicht nur dem Code vertrauen, sondern auch der Denkweise dahinter, und im Moment wirkt es wie ein Tool nur für den internen Gebrauch bei Anthropic.

  • Bun ist wirklich ein spannendes Projekt, aber die Zahl der Segmentation Faults in den Issues war für mich zu beunruhigend, um es in ernsthaften Produktionsumgebungen einzusetzen.
    Diese Richtung könnte ein Weg sein, das zu beheben, also bleibt abzuwarten.
  • Ich verstehe das, aber mein Ausgangspunkt ist ziemlich anders.
    Als langjähriger Deno-Fan wirkte Bun auf mich wie ein weniger ambitioniertes Deno, und weil ich Zig nicht lernen wollte, war es selbst als Hobby unwahrscheinlich, dass ich mich direkt mit Bun beschäftigen würde.
    Aber in den letzten Jahren habe ich versucht, recht große TypeScript-Codebasen auf eine weniger runtime-gebundene Weise zu pflegen, und dadurch wurde ich Bun gegenüber immer offener. Ich wollte eigentlich keine bestimmte TypeScript-Runtime zur Anforderung machen, aber Bun bot immer wieder Gründe wie Postgres, SQLite, S3, WebSockets, lokales Secret-Storage, Bundling, Kompilierung und hohe Geschwindigkeit, ähnlich wie Deno.
    Inzwischen baue ich mehrere API-Server und Frontend-App-Server als einzelne ausführbare bun build --compile --bytecode-Dateien, die sich fast überall ausführen und deployen lassen.
    Ich halte diesen Ansatz allerdings nicht für verbreitet, und falls dieses LLM-basierte Porting scheitert, bin ich in genau der richtigen Position, um alle meine Bun-Entscheidungen zu bereuen.
    Wenn es aber nicht scheitert, ist es spannend. Dann wäre es ein Beispiel dafür, was mit LLMs möglich ist, und dass Bun künftig in Rust entwickelt wird, wäre für mich ein Pluspunkt.
    Und selbst wenn es scheitert, ist das als Information wichtig. Bun ist eine der großen TS/JS-Runtimes, und Anthropic hat enorme Ressourcen, Zugriff auf die neuesten Modelle und praktisch unbegrenztes Budget. Wenn sie es nicht schaffen, heißt das fast, dass es derzeit wirklich noch nicht möglich ist.
  • Mich würde interessieren, warum dich Bun mehr angesprochen hat als Deno.

• Wenn man Zig in unsicheres Rust übertragen wollte, verstehe ich nicht, warum man nicht einfach ein Übersetzungstool gebaut hat.
  Mit einer 1:1-Abbildung der Sprachkonstrukte und hart kodierten Mustern aus der Codebasis hätte man eine deterministische Konvertierung bekommen können; wie ein Freund sagte, hätte man auch so etwas wie „zig translate-c an c2rust anschließen“ versuchen können.
  Das jetzige Ergebnis ist noch weniger vertrauenswürdig als die Eingabe. Die Eingabe war nicht speichersicher, aber von Menschen geschrieben; die Ausgabe ist ebenfalls nicht speichersicher, dazu vibe-coded und wirkt, als hätte nie ein Mensch sie richtig angesehen.
  Ich verstehe nicht, wozu man agentische KI für so einen Zweck derart missbraucht.

  • Wer schon einmal das Ergebnis von c2rust gesehen hat, wird das kaum so sagen.
    Es ist furchtbar, weil es unsichere Pointer-Semantik aus C mit einer Bibliothek unsicherer Funktionen in Rust nachahmt.
    Ich hatte mir vor ein paar Jahren einmal einen OpenJPEG-Bug angesehen, und jemand hatte ihn testweise mit c2rust konvertiert; das übersetzte unsichere Rust produzierte an genau derselben Stelle wie der C-Code einen Segmentation Fault.
    Kompatibel, aber nicht sicher.
    Der Kernpunkt ist: String-Manipulation sollte man weder in C noch in unsicherem Rust machen. Das ist für diese Aufgabe völlig das falsche Werkzeug.
  • Haben sie doch. Ein sehr dynamisches Übersetzungstool.
  • „zig translate-c an c2rust anschließen“ funktioniert nicht so, wie man denkt.
    Solche Tools machen viele Fehler und erzeugen sehr ausschweifenden, schwer nachvollziehbaren Code.
    Für kleine Apps mag das gehen, aber nicht für eine komplette Neuschreibung.
  • Ich habe in einem anderen Thread fast dasselbe gesagt, habe aber auf das Schreiben von Software einen etwas anderen Blick.
    Statt Zig nach Rust zu übersetzen, halte ich es für besser, einen JPEG-Parser zunächst in statischem Python zu schreiben und ihn dann in idiomatische Strukturen für Zig und Rust herunterzubrechen.
    Dafür habe ich einen Parser für einen Python-Dialekt gebaut, der genau für diesen Zweck gedacht ist, und ich will einige Rust-/Zig-Funktionen übernehmen, die die Übersetzung erleichtern, dabei aber mit dem Großteil von Python-Code kompatibel bleiben.
    Der JPEG-Parser ist auch in den Beispiel-Assets enthalten.
    https://github.com/py2many/static-python-skill
    https://github.com/py2many/spy-ast
  • Der richtige Weg, eine Codebasis in eine andere Sprache zu portieren, ist, den Syntaxbaum zu parsen und deterministische, verifizierte Transformationen anzuwenden.

• Dieses Issue führt zu Missverständnissen.
  Das Problem ist nicht die bloße Existenz von Undefined Behavior, die miri finden kann, sondern dass eine API exponiert wurde, die in sicherem Code Undefined Behavior auslösen kann. miri findet das auch nur, wenn man einen Test schreibt, der es belegt.
  Dass so etwas während des ersten Portings aus einer unsicheren Sprache passiert, ist nicht völlig unvernünftig.
  Das Bun-Team scheint auch danach die Funktionen zu überprüfen, die unsicheren Code kapseln.
  Dass man in der Portierungsphase einige unsichere Funktionen vorübergehend fälschlich als sicher markiert, ist an sich kein riesiges Problem, aber es ist etwas seltsam, das so in das Haupt-Repository zu mergen.
  Das eigentliche Problem entsteht, wenn Code in diesem Zustand veröffentlicht wird.
  Schade ist, dass sie die Tests nicht sofort so eingerichtet haben, dass sie mit miri laufen. LLMs reagieren schließlich gut auf gute Tests.
  Ich beurteile das nicht wegen dieses GitHub-Issues, sondern weil ein anderer Test [1] tatsächlich Undefined Behavior aufruft, das miri finden würde. Der betroffene Code scheint allerdings nirgends verwendet zu werden, daher dürfte die reale Auswirkung gering sein.
  Es ist noch früh im Porting, also kann das später noch behoben werden, und womöglich kann man unnötigen unsicheren Code ganz entfernen.
  [1] https://github.com/oven-sh/bun/blob/4d443e54022ceeadc79adf54... - Pointer, die aus der ersten veränderbaren Referenz abgeleitet wurden, werden ungültig, wenn neue veränderbare Referenzen auf dasselbe Objekt erzeugt werden. In C-Begriffen kann man „veränderbare Referenz“ als „restrict-Referenz, über die triviale Änderungen vorgenommen werden“ verstehen.
  Korrekt wäre es, alle Pointer aus derselben veränderbaren Referenz abzuleiten; genau das wurde aber nicht gemacht.
  Wenn jetzt alle auf GitHub stürmen und das Issue zuspammen, sinkt nur die Wahrscheinlichkeit, dass öffentlich gearbeitet wird. Das sollte man lassen.
  Und es ist besser, das Urteil auszusetzen, bis der Stand überhaupt veröffentlichbar ist. Einen Zwischenstand zu bewerten ist weder fair noch besonders interessant.

  • Sobald ein Projekt 1.0 erreicht hat, erwarten viele Menschen, dass der main-Branch immer funktioniert.
    CI/CD beruht letztlich auf der Annahme, dass jeder Commit funktionieren sollte.
    Nicht funktionierender Code in Arbeit, etwa für eine komplette Neuschreibung, gehört in einen Branch.
    Nur so kann man bei Dingen wie Sicherheitsfixes einen funktionierenden main behalten.

• Dieses Ergebnis überrascht nicht, weil die angeforderte Art der Arbeit nahezu ein wortgetreues Porting war.
  Man könnte argumentieren, dass es besser ist, Bun zuerst in eine Sprache mit stärkerem Typsystem zu übertragen und dieses Typsystem dann als Sprungbrett für spätere Verbesserungen zu nutzen.
  Das scheint besser, als schon im ersten Schritt Perfektion zu verlangen.

  • Genau das tun sie ja tatsächlich.
    Sie arbeiten eingehende Issues nach und nach ab.
  • Wenn man dem Prompt einfach „sorge dafür, dass es kein Undefined Behavior gibt“ hinzufügt, wird es schon passen.
  • Jetzt kann man die Neuschreibung wohl mit Tools wie miri unter Druck setzen und Claude Code die Verbesserungen automatisch machen lassen.
  • Dass in größtenteils wortgetreu übersetztem, teilweise unsicherem Rust-Code Undefined Behavior auftaucht, ist nicht überraschend.
    Enttäuschend ist allerdings, dass die APIs des Rust-Codes nicht als unsafe markiert wurden, obwohl sie Undefined Behavior auslösen können.
    Bei so einer Übersetzung wäre ich konservativ vorgegangen und hätte anfangs alles oder zumindest fast alles als unsafe markiert.
    Danach könnte man die Sicherheit einzelner Teile schrittweise verifizieren.

• Ehrlich gesagt war ich etwas überrascht von der Aussage, man habe das in einer Woche vollständig zum Laufen gebracht.
  Mein Nebenprojekt mit ähnlichem Anspruch ist https://tsz.dev, und ich kann nicht behaupten, erfolgreich zu sein.
  Ich füge ständig Tests hinzu, um das Verhalten zu prüfen, und selbst nachdem alle TypeScript-eigenen Tests bestanden wurden, finde ich erwartungsgemäß weiterhin Bugs.
  Sich am Verhalten von tsc auszurichten, ist wirklich eine extrem hohe Messlatte.
  https://github.com/type-challenges/type-challenges
  Ich habe nichts dagegen, mit LLMs viel Code zu schreiben, aber jetzt, da man Code in diesem Tempo produzieren kann, muss die Verifikation 100-mal robuster sein.

  • Mich schockiert, dass man in einem „Experiment“ binnen einer Woche Code im Millionenzeilenbereich gemergt hat, der höchstwahrscheinlich kaum geprüft wurde.
    Gegen Agenten an sich habe ich nichts, aber so etwas zu überstürzen und die Community dann damit zu überfallen, wirkt sehr amateurhaft.
    So etwas würde man eher von einem übermotivierten Junior Engineer erwarten.
  • https://tsz.dev/sound-mode/
    Das ist großartig. Davon braucht TypeScript mehr, und hoffentlich wird es bekannter, sodass Microsoft es vielleicht übernimmt.
    Nur würde ich mit dem Namen sound mode vorsichtig sein.
    In dem Satz „kein Beweis mathematischer Soundness und macht Third-Party-.d.ts-Dateien nicht wahr“ stecken zwei völlig unterschiedliche Dinge.
    Erstens ist Soundness ein mathematisches Konzept. Wenn etwas sound ist, dann ist es tatsächlich sound, und das bedeutet, dass man dem Compiler vertrauen kann, ohne jedes Detail manuell prüfen zu müssen.
    Implementierungsbugs können natürlich zu Fehlverhalten führen, aber die lassen sich beheben; Soundness bedeutet, dass Spezifikation oder Typsystem selbst theoretisch keinen solchen Fehler enthalten.
    Zweitens ist es in realen Sprachen völlig normal und erwartbar, ungeprüfte Features zu brauchen, von denen man annimmt, dass Menschen sie korrekt benutzen, etwa Haskells unsafeCoerce oder Javas sun.misc.unsafe.
    Das eigentliche Problem entsteht, wenn das Typsystem bricht, obwohl solche Features gar nicht verwendet wurden.
  • Es als funktionsfähig zu bezeichnen, ist etwas übertrieben.
    Ich habe den Code nur ein paar Minuten angesehen, aber sobald man Optimierungen einschaltet, dürfte er heftig auseinanderfallen.
  • Vermutlich haben sie das monatelang geplant und damit experimentiert.
    Mit einer großen bestehenden Testsuite, Werkzeugen zur Parallelisierung von Agenten und praktisch unbegrenztem Token-Budget muss man nicht zu niedergeschlagen sein.

• Es gibt ein Buch [0], das meine Sicht auf Aufmerksamkeit und Medien stark verändert hat.
  Das Buch selbst ist nicht besonders gut, trifft aber einen hier relevanten Punkt.
  Es gibt eine enorme Asymmetrie zwischen der Reichweite großer, spektakulärer Ankündigungen – etwa der Botschaft „Bun wurde in wenigen Wochen in speichersicheres Rust neu geschrieben“ – und der Reichweite von Korrekturen, etwa in Fußnoten alter Artikel oder in GitHub-Issues.
  Diese Asymmetrie wird in der Marketing- und PR-Branche gut verstanden und aktiv genutzt.
  [0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

  • Bei der aktuellen Stimmung scheint es viele Menschen zu geben, die jede Kritik am Code aufgreifen und maximal verstärken wollen.
    Im Moment wirkt das meiste davon eher oberflächlich.
    Das Mergen eines großen LLM-unterstützten Portings war eindeutig eine sehr kühne Entscheidung, aber vieles von dem, was die Leute am tatsächlichen Ergebnis kritisieren, erscheint mir nicht schlimmer als bei anderen Portierungen im laufenden Zustand.
    Jedes gefundene Problem wird übertrieben aufgeblasen.
  • Ich frage mich zunächst einmal, ob sie überhaupt behauptet haben, es sei speichersicher.
    In jeder Diskussion zu diesem Thema gab es Dutzende Kommentare darüber, dass die vibe-coded Codebasis mit nicht auditierten unsafe-Blöcken kurz vor der Explosion stehe und offenbar Leute sie oberflächlich reviewt hätten, die Rust nicht verstehen.
    Teilweise wirkte es sogar so, als wären manche schon wütend über die bloße Vorstellung, dass man irgendeine Programmiersprache verstehen müsse.
  • Ist das nicht genau die Idee hinter dem Zitat „Eine Lüge ist schon um die halbe Welt, bevor die Wahrheit ihre Schuhe angezogen hat“?
  • Nicht nur Marketing und PR, auch Mainstream-Medien wissen, dass Unsinn zuerst zu verbreiten und später zurückzunehmen einen bleibenden Effekt hat.
    Menschen erinnern sich oft an den ursprünglichen Artikel oder die Überschrift, sehen die Korrektur aber nie.
  • Ich dachte eher, du würdest das Problem in die andere Richtung meinen.
    Das Porting läuft noch, es gab also keine große, spektakuläre Ankündigung, und es ist weder abgeschlossen noch veröffentlicht.
    Die spektakulären Aussagen, die ich sehe, sind eher hit-and-run-artiger Spott über unfertigen Code und Versuche, so zu tun, als hätte das Team behauptet, es sei fertig oder perfekt.
    Die Neuschreibung war eine Codeübersetzung, die als Ausgangspunkt dienen sollte.
    Das Bun-Team hat nie groß verkündet, der Code sei jetzt speichersicher; es hat klar gesagt, dass es ein Ausgangspunkt ist.
    Zu erwarten, dass er sofort perfekt ist und alle Speicherprobleme des ursprünglichen Zig-Codes löst, heißt, nicht gegen die tatsächlichen Aussagen des Bun-Teams zu argumentieren, sondern gegen eine erfundene Ankündigung.
    Ich frage mich auch, ob überhaupt jemand versucht hat, diese Speicherprobleme auf die ursprüngliche Codebasis zurückzumappen.

• Solche Fehler waren zu erwarten.
  Für Leute, die Stabilität brauchen, hat man die stabile Version in Zig belassen, und ich gehe davon aus, dass die Fehler am Ende behoben werden.

  • Diese Fehler wären durchaus vermeidbar gewesen.
    Im Rust-Ökosystem gibt es bekannte Tools, die so etwas finden, und selbst wenn sie nicht jedes Undefined Behavior aus Fehlern in unsafe-Blöcken entdecken, gilt es als gute Praxis, sie auszuführen.

• Am meisten Sorge macht mir die Meta-Diskussion.
  Anfangs habe ich die Maintainer kritisch gesehen, die dieses GitHub-Issue als off-topic geschlossen haben.
  Dann habe ich aber gesehen, dass die GitHub-Oberfläche automatisch eine ganze Gruppe von Nachrichten eingeklappt hatte, die keinerlei Informationswert hatten und offenbar aus Foren oder Community-Discords herübergespült worden waren.
  Das bringt alle in eine Lose-lose-Situation.
  Wer ein gravierendes Problem entdeckt, über das sich große Teile der relevanten Community zu Recht Sorgen machen könnten, hat gute Gründe, es so breit wie möglich bekannt zu machen.
  Es ist eine inhaltliche Reaktion auf eine jüngste Änderung, und am Wahrheitsgehalt ändert sich nichts, nur weil man den Tonfall kritisiert.
  Das Problem ist, dass zusätzliche Aufmerksamkeit die Diskussion buchstäblich abwürgt.
  Das kann auf Maintainer-Seite auch Leuten Schutz bieten, die emotionaler oder fast schon AI-psychotischer entscheiden.
  Projekte mit einer Belagerungsmentalität, in denen Kritik blockiert und ignoriert wird, geraten sehr schnell aus der Spur.
  Umgekehrt ist in Projekten, die ihre Maintainer nicht vor Angst und Pathologien rund um KI schützen, Maintainer-Burnout unvermeidlich.

• Diese Bun-Neuschreibung fühlt sich wie ein potenzielles Event für Mythos-Marketing an.

  • Bislang hat weder das Bun-Team noch jemand bei Anthropic das als mehr vermarktet, als es ist: ein Wechsel zu einer speichersichereren Sprache mit besseren Garantien des Compilers.
    Der bisherige Hype und die Aufmerksamkeit kamen größtenteils aus negativen Reaktionen von KI-Gegnern.
    Ich glaube, da spielt auch stark mit hinein, dass sich die Wahrnehmung von Anthropic selbst durch einige jüngere Entscheidungen verschlechtert hat.
  • Für mich sieht das einfach nach einem Corporate Rug Pull aus.
    Als hätte nur noch das, was Anthropic braucht, Priorität und der Rest wäre egal.
  • Sie haben die Neuschreibung mit einem vermutlich unermesslichen Budget für Tokens laufen lassen.
    Dann posaunt man groß herum und schreibt Blogposts wie „Claude Code hat dem Bun-Team geholfen, über eine Million Zeilen Zig in Rust neu zu schreiben“, und die VCs bekommen glänzende Augen.
    Dann fällt es schon an den grundlegenden Checks durch.
    Dann lässt man Mythos die Codebasis weiter zerreißen und gibt wer weiß wie viel Geld aus.
    Dann schreibt man noch einen separaten Blogpost.
    Betrüger und Naive applaudieren und verteidigen das gegen die „wahnhafte Anti-AI-Menge“.
    Die VCs werden noch aufgeregter.
    So verdient man Geld.
    Und danach geht es dann in die Richtung, dass man jetzt auch noch Software Engineers abschaffen müsse.

• Es steckt bereits eine weitere unsichere Sprachbindung in einer Codebasis aus einer unsicheren Sprache; ich verstehe nicht, warum man annimmt, dass so etwas sofort perfekt umgesetzt aussehen müsste.