- Die rsync-Wartung befindet sich in einer Lage, in der ein explosionsartiger Anstieg von Sicherheitsmeldungen mit Kontroversen um den Einsatz von KI zusammenfällt, wodurch Tests, Code-Coverage, Multi-Plattform-CI, Sicherheitsscans und Defense-in-Depth notwendig geworden sind
- Die neue Python-Test-Suite ersetzt die bisherige Struktur aus Shell-Skripten, während Entwurf und Validierungsplan vom Maintainer übernommen wurden; Claude, Codex und Gemini wurden zur Unterstützung bei repetitiven Arbeiten eingesetzt
- Das Release 3.4.3 priorisierte Sicherheitsfixes, führte dabei aber Regressionen in einigen gültigen, jedoch ungewöhnlichen Anwendungsfällen ein, die von den bestehenden Tests und manuellen Tests nicht erfasst wurden
- pytest wurde zwar in vielen anderen Projekten genutzt, passte aber nicht zu den spezifischen Anforderungen der rsync-Test-Suite; deshalb wurde ein separater Ansatz entworfen, und LLMs gelten als Werkzeuge, die vorsichtig eingesetzt werden sollten, aber nützlich sind
- Für die weitere Richtung wird zwischen 3.4.4 zur Abmilderung von Regressionen und 3.5.0 mit größeren Sicherheitsänderungen entschieden; openrsync scheitert derzeit in 85 von 98 Tests der neuen Test-Suite
Explosionsartiger Anstieg von Sicherheitsmeldungen und stärkere Abwehr
- Der rsync-Maintainer erlebt derzeit wie andere Entwickler von Open-Source-Paketen einen starken Zustrom von Sicherheitsmeldungen; viele davon sind KI-generiert, aber einige enthalten auch sorgfältige und hochwertige manuelle Analysen
- Durch die Zunahme der Meldungen braucht rsync nun eine gründlichere Test-Suite, Code-Coverage-Analysen, CI-Tests auf mehr Plattformen, gezieltes Scannen nach Sicherheitsproblemen und Defense-in-Depth-Techniken
- Der Maintainer ist im Ruhestand und würde lieber mehr segeln, hat wegen des nötigen Arbeitsaufwands aber verschiedene KI-Werkzeuge eingesetzt und bereut diese Entscheidung nicht
Python-Test-Suite und KI-gestützte Arbeit
- Die bestehende rsync-Test-Suite auf Basis von Shell-Skripten wurde in Python neu geschrieben, wobei die zentrale Architektur und der Validierungsplan direkt vom Maintainer verantwortet wurden
- Claude wurde für repetitive Arbeiten verwendet, Codex und Gemini zum Gegenprüfen; es war also nicht einfach ein Auftrag nach dem Motto „wandle die Test-Suite in Python um“
- Der Maintainer hat alles selbst geprüft, viel CI-Zeit investiert und ist später dazu übergegangen, die meisten Tests in mehreren lokalen VMs auszuführen, um Wartezeiten in der CI zu verringern
- Der Vermerk
co-authored by claude in der Commit-Historie zeigt nach dieser Einschätzung nur einen Teil der gesamten Software-Engineering-Arbeit
LLM-Debatte, pytest-Entscheidung, Regressionen in 3.4.3
- Die Position ist, dass LLMs nicht nutzlos werden, nur weil man ihre Funktionsweise kennt; man müsse sie vorsichtig einsetzen, aber sie seien in der heutigen Wartungsumgebung für Software Engineering und IT-Sicherheit nützliche Werkzeuge
- rsync 3.4.3 war bewusst ein Release, das sich auf die Behebung von Sicherheitsproblemen konzentrierte, wodurch einige gültige, aber ungewöhnliche Anwendungsfälle von den Änderungen betroffen waren
- Diese betroffenen Anwendungsfälle waren weder in der bisherigen rsync-Test-Suite noch in manuellen Tests enthalten; die über Issues und PRs im GitHub-Repository gemeldeten Regressionen werden nun schrittweise bearbeitet
- pytest wird in vielen anderen Projekten genutzt, aber einige der für die rsync-Test-Suite nötigen Aufgaben gelten dort als sehr schwer umsetzbar, weshalb ein eigener Testansatz entworfen wurde
Nächstes Release und Ausbau der Sicherheitstests
- Sicherheitsmeldungen gehen weiter ein, und derzeit laufen Arbeiten an mehreren CVEs
- Weitere Entwickler mit Fähigkeiten in Systementwicklung und Sicherheitswissen sind hinzugekommen; einige davon wurden durch die jüngste Empörung überhaupt erst sichtbar
- Als Nächstes steht die Wahl zwischen 3.4.4 zur Abmilderung einiger Regressionen und 3.5.0 mit wesentlich größeren Änderungen an; 3.5 würde den Sicherheitsstandard von rsync deutlich anheben, ist aber ein Release mit großem Änderungsumfang
- Um ein großes Änderungspaket schnell anwenden zu können, brauchte Software wie rsync eine umfassende Test-Suite; aus diesem Bedarf entstand die Neuschreibung der Test-Suite
- Das 3.5-Release soll zusätzliche Tests enthalten, die sicherheitsbezogene Probleme abdecken
Vergleich mit openrsync und Bitte um Code-Review
- Auf den Trend, openrsync für bestimmte Plattformen zu paketieren, lautet die Reaktion, dass man die neue rsync-Test-Suite auch auf openrsync anwenden könne
- Das Ausführungsbeispiel ist der folgende Befehl
./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp
- openrsync fällt derzeit in 85 von 98 Tests durch; viele Fehler hängen zwar mit in openrsync fehlenden Funktionen zusammen, werden aber trotzdem nicht als gutes Ergebnis bewertet
- Statt noch mehr Empörung zu äußern, wird darum gebeten, den veröffentlichten Code tatsächlich zu prüfen und konstruktive Kritik zu üben
1 Kommentare
Lobste.rs-Meinungen
Wenn man das Zitat liest, wirkt es so, als wolle der Autor segeln gehen, fühle aber zugleich Druck durch die Projektwartung und sehe im Einsatz von LLMs eine Lösung, mit der beides möglich sei
Es ist in Ordnung, im Ruhestand lieber segeln zu gehen und deshalb keine Bugs zu beheben, und es ist auch in Ordnung, Bugs in einem Open-Source-Projekt nicht zu beheben. Man muss das nur öffentlich und transparent sagen. Wie früher schon gesagt wurde, reicht ein „Patches willkommen“ völlig aus. Das gilt umso mehr, wenn ressourcenstarke Unternehmen von dem Projekt abhängen
Ich wünschte, mehr Maintainer und Entwickler könnten ihren Ruhestand und das Segeln genießen, ohne den Druck zu spüren, bei der Open-Source-Wartung auf die „Hilfe“ von LLMs angewiesen zu sein. Wenn er trotzdem im rsync-Projekt mit LLMs experimentieren will, ist das seine Entscheidung. Das gilt auch dann, wenn andere, mich eingeschlossen, nicht zustimmen
Wer aus welchem Grund auch immer Open-Source-Entwickler schikaniert, scheint zu vergessen, dass freie Open-Source-Software kein Produkt, sondern ein Geschenk ist
Wer nur von außen zuschaut, kann das Projekt forken, wenn es ihm nicht gefällt. Andrew kann an dem Projekt so arbeiten, wie er es möchte, und unsere Kommentare und Meinungen sind dafür nicht unbedingt nötig
Der hoffnungsvolle Teil ist, dass sich langfristig vielleicht jemand anderes findet, der die rsync-Wartung übernimmt. Tridge hat das Projekt früher schon einmal an einen neuen Maintainer übergeben
Ich habe einen Vortrag über Fälle gehört, in denen die OpenJS Foundation einigen Projekten Finanzierung und Unterstützung beim Übergang geboten hat, um von einem einzelnen Maintainer zu Team-Wartung zu wechseln, und darüber für LWN geschrieben; der Text soll heute veröffentlicht werden. Projekte wie rsync brauchen deutlich mehr solcher Unterstützung
Sicherheitsprobleme erzeugen viel Druck, sind stark öffentlich sichtbar und liegen oft weit entfernt von dem Kern eines Projekts, den der Maintainer eigentlich interessant findet
Wartung bringt viel Verantwortung mit sich und macht nicht immer Spaß, aber ich bin dankbar, wenn freie Open-Source-Maintainer sogar solche Aufgaben übernehmen. Es scheint nicht viele zu geben, die das tun
Es kann sein, dass die Kosten für das Erreichen eines bestimmten Ziels ohne LLM-Hilfe zu hoch wären und mit LLM-Hilfe auf ein vernünftiges Maß sinken
Positiv betrachtet bedeutet es, dass ein Open-Source-Maintainer, der eine gesunde Work-Life-Balance bewahren will, mit LLMs seine Arbeitslast senken und seine gewünschten Ziele leichter erreichen kann
Der herausgegriffene Teil des Zitats ist nur ein Ausschnitt aus der Einleitung, und dieser Text ist klar ein vorsichtig und nuanciert geschriebener Beitrag, nicht einfach ein grundlegender Text über Open-Source-Wartung
Noch merkwürdiger ist, dass der Kontext direkt vor dem Zitat weggelassen wurde. Dort ging es darum, dass die Zahl der Meldungen stark gestiegen ist und rsync seine Abwehr deutlich verstärken musste, mit einer viel gründlicheren Testsuite, Code-Coverage-Analyse, CI-Tests auf mehr Plattformen, der Suche nach Sicherheitsproblemen und zusätzlichen Techniken zur Defense in Depth
In diesem Fall ist der Autor im Ruhestand, aber in anderen Open-Source-Projekten können Menschen mit einem Job oder anderen Verpflichtungen von einem ähnlichen Anstieg der Arbeitslast mitgerissen werden. Ehrlich gesagt irritiert es mich, dass dieser Kommentar so viele Empfehlungen bekommt, und er wirkt nicht wie ein in gutem Glauben geschriebener Beitrag. Er erscheint mir mindestens nur geringfügig sorgfältiger als ein Kommentar, den jemand nach dem bloßen Lesen der Überschrift schnell hingeworfen hat
Ich will Belästigung weder entschuldigen noch gutheißen, aber in dieser Verteidigung fehlt ein Grund
Die Erklärung lautet, der Autor habe ein Design fürs Vibe-Coding erstellt, den resultierenden Code überprüft, sich mit Code und Chatbots ausgekannt, Vibe-Coding vorsichtig behandelt und versucht, ein Gleichgewicht zwischen Sicherheit und Funktionsregressionen zu finden. Das klingt plausibel, aber tatsächlich gab es Regressionen, und der Autor ist nicht einmal bis zu deren Ursache vorgedrungen
Er sagte, „AI-Tools seien gut bei einfachen Aufgaben, also habe ich ihnen solche Arbeiten übertragen“, aber das stimmt nicht. Chatbots sind tatsächlich schlecht im eigentlichen Schreiben. Das ist der Kernpunkt, und der Autor scheint das nicht einmal zu erkennen
Es wäre gut zu prüfen, ob die Zahlen zuletzt wirklich gestiegen sind. Regressionen an sich sind nichts Seltenes, und möglicherweise suchen Leute nur nach einem Vorwand, um Andrew anzugreifen
Der Autor hat eingeräumt, dass es in einigen Anwendungsfällen der Release rsync 3.4.3 Regressionen gab, und erklärt, dass bei dieser Release bewusst mehr Gewicht auf die Behebung von Sicherheitsproblemen gelegt wurde und einige gültige, aber ungewöhnliche Anwendungsfälle von den Änderungen betroffen waren
Diese Fälle waren weder Teil der bestehenden rsync-Testsuite noch der manuell durchgeführten Tests, und er bearbeitet die Regressionen gerade. Er dankte auch den Leuten, die sie per Issue oder PR im GitHub-Repository gemeldet haben. Außerdem entschuldigte er sich, falls der eigene Anwendungsfall betroffen war, und sagte, wer das Sicherheitsrisiko in Kauf nehmen wolle, könne auch die frühere Release verwenden
Ich höre seit etwa einem halben Jahr immer wieder Sätze wie „Die Welt des Software Engineerings hat sich in den letzten Monaten dramatisch verändert“ und „Die Welt der Softwarewartung hat sich in den letzten Wochen angesichts von IT-Sicherheit und einer Meldeflut völlig verändert“, und das ermüdet.
Wenn diese Meldeflut durch LLMs verursacht wird, wirkt es kaum glaubwürdig, ausgerechnet in LLMs die Lösung zu suchen.
Gleichzeitig glaube ich sofort, dass es furchtbar sein muss, heute etwas Populäres zu warten. Vielleicht wäre es für ihn am besten, sich einfach zurückzuziehen und den echten Ruhestand zu genießen, statt noch mehr aus begrenzter Rechenzeit herauszupressen.
Wenn es auch nur halb so nützlich wäre, wie die Leute behaupten, würde sein Nutzen für sich selbst sprechen.
Trotzdem lohnt es sich, jemandem wie Tridgell zuzuhören. Und die „Flut“ an Sicherheitsmeldungen muss man ernst nehmen. Ein Sicherheitsproblem ist ein Sicherheitsproblem, egal wer oder was es gefunden hat. Deshalb fühlt sich dieser Text anders an als die üblichen ermüdenden Angriffe.
Am Ende könnte das in eine Abwärtsspirale immer größerer LLM-Abhängigkeit führen.
Warum ist das die falsche Richtung? Heißt das, es wäre besser, wenn niemand LLMs hätte?
LLM-unterstützte Entwicklung muss nicht zwangsläufig zu „Müll-Ergebnissen“ führen.
Ich bin dankbar, dass dieser Text geschrieben und geteilt wurde. Besonders aufgefallen ist mir die Stelle, an der überlegt wird, ob man mit 3.4.4 einige Regressionen abmildern oder direkt auf das deutlich größere 3.5.0 mit viel weitreichenderen Änderungen gehen soll.
Falls der Autor mitliest: 3.4.4 wirkt hier wie der richtige Ansatz. Wenn es im letzten Release Regressionen gab, würden viele es als leichtsinnig ansehen, sofort auf ein großes 3.5.0 zu gehen. Wenn man den Leuten hilft, den Unterschied besser zu verstehen, dürfte das die Sorge verringern.
Zu der Stelle, dass es vielleicht doch keine gute Idee war, die Kernstruktur der neuen Testsuite zuerst öffentlich auf
masterzu entwickeln, weil das Ärger ausgelöst habe: Ich glaube nicht, dass weniger Transparenz die Wahrnehmung oder Reaktion verbessern würde. Bestenfalls würde das den größeren Gegenwind nur nach hinten verschieben.Es ist nicht fair zu sagen, man solle die neue rsync-Testsuite doch auf openrsync laufen lassen. samba rsync ist Protokoll 32, openrsync hingegen Protokoll 27, und es erhebt auch gar nicht den Anspruch auf vollständige Funktionsgleichheit.
Medium und Cloudflare, was für eine schreckliche Kombination, die man nicht zusammenbringen sollte.
https://archive.is/qbyVA
Open-Source-Wartung ist undankbare Arbeit. Tridge wollte die technischen Schulden der Testsuite beheben und verantwortungsvoll auf die von LLMs erkannte CVE-Flut reagieren, wurde dabei aber wohl von Hyrums Gesetz getroffen. Der 3.4.4-Plan ist die weniger schlechte Option, und am Ende muss man es wohl einfach durchziehen.
Bei diesem Thema bin ich hin- und hergerissen. Einerseits denke ich, dass Sicherheit nur dann gewährleistet werden kann, wenn Menschen den Code direkt schreiben.
Denn während man Code schreibt, denkt man über ihn nach und findet Fehler frühzeitig. Ich schreibe selbst deutlich besser, wenn ich direkt code, als wenn ich Code nur prüfe. Beim Review geht vieles einfach durch, weil ich nicht jede Zeile sorgfältig durchdacht habe.
Andererseits hat Andrew, ganz unabhängig von der grundlegenden Tatsache, dass Belästigung inakzeptabel ist, das Recht, sein Projekt in seiner Freizeit so zu betreiben, wie er möchte. Wenn er LLMs verwenden will, stimme ich zwar nicht zu, aber es ist sein Projekt und seine Entscheidung. Wenn mir das nicht gefällt, muss ich meine Backups auf restic oder borgbackup umstellen oder rsync forken.
Um das klarzustellen: Ich bin nicht grundsätzlich gegen Vibe-Coding. Bei uns in der Firma wird das halbwegs erzwungen, und für den langweiligen, nicht neuartigen Glue-Code, der heute den Großteil meiner Arbeit ausmacht, ist es einigermaßen brauchbar. In meiner Freizeit nutze ich es aber nicht.
rsyncohnehin nicht gerade die ideale Lösung.Es hilft nämlich nicht bei der Wiederherstellung, wenn Dateiinhalte beschädigt wurden. Ein Tool wie restic ist deutlich besser und bewahrt auch frühere Versionen von Dateien auf, um genau solche Fälle abzudecken. Es verfolgt sogar Löschungen, sodass man weiß, welche Dateien nicht mehr relevant sind.
Ich habe Erfahrung mit Anwendungssicherheit, könnte einige Exploits herauspicken und würde manche wohl auch in einem Review finden. Aber ich bin derzeit nicht so gut wie führende LLMs darin, einfach immer wieder nach dem Muster „Finde noch pathologischere Fälle“ zu iterieren.
So habe ich in beliebter Software, in meinem eigenen Code, in verwendeten Bibliotheken und in alternativen Implementierungen ohne großen Aufwand Probleme gefunden. Die Zeit und Hartnäckigkeit, die ein Mensch aufbringen kann, ist damit überhaupt nicht vergleichbar.
In einer Organisation ist Sicherheitssoftware breit ausgerollt, um Probleme zu verhindern, zu erkennen und darauf zu reagieren. In jedem Bereich gibt es immer Lücken und immer noch mehr zu tun. Organisationen wissen, dass sie nicht perfekt sein können, und ziehen es womöglich vor, Verbesserungen ihrer Sicherheitslage zu akzeptieren, selbst wenn sie unvollkommen sind, statt gar keine Verbesserung zu haben. Der von LLMs gelieferte Kompromiss ist ein Teil davon.
Wo dieser Kompromiss liegt, hängt vom Kontext ab, aber nur selten lautet er: „Jeder Code muss von Hand geschrieben werden.“
Das gilt auch für einen Server wie rsync. Wie der Autor sagt, kann ein großes Refactoring nötig sein, um ihn robuster und widerstandsfähiger zu machen. Wenn man mit einem LLM in Richtung Privilegientrennung refaktorieren und dadurch eine kleinere vertrauensbasierte Codebasis schaffen kann, könnte man einige Bugs außerhalb dieses Bereichs in Kauf nehmen.
Ich kenne den konkreten Kontext von rsync nicht, aber ich glaube, dass der Autor innerhalb der begrenzten Ressourcen, die solche Projekte typischerweise haben, die beste Entscheidung für das Projekt und seine Nutzer trifft.
Dafür bietet rclone Parallelisierung und nutzt die verfügbare Netzwerkbandbreite deutlich effizienter.
Das gibt eine Obergrenze dafür, welche Art von Problemen überhaupt möglich ist.
Die Untergrenze sind Bugs und Schwachstellen, die ich finde, die jemand anderes findet oder die etwas anderes findet, zum Beispiel ein LLM.
Ein Mensch, der selbst geschriebenen C-Code wie etwa rsync überprüft, würde in diesem Spektrum kaum als besonders günstige Position gelten. Das ist in keiner Weise als Vorwurf an Andrew gemeint.
Ich habe Verständnis für einen pensionierten Maintainer, der segeln möchte, aber ich glaube nicht, dass dieser Kontext grundsätzlich etwas ändert.
Tridgell schuldet uns keinerlei Arbeit und ist frei, in Rente zu gehen und segeln zu gehen. Wenn er das will, wünsche ich ihm alles Gute. Ich kann auch nachvollziehen, dass er sich verantwortlich fühlt, aber wenn ich zwischen den Zeilen richtig lese, empfindet er das wohl zumindest teilweise als Belastung.
Aber rsync ist kritische Software, und ich finde, wer sie warten will, sollte einen bestimmten Qualitätsstandard einhalten. Wenn die Arbeit des Maintainers diesen Standard nicht erreicht, ist das ein Fehler. Das ist trotzdem kein Grund für Belästigung. Zu sagen, dass etwas ein Fehler ist, heißt nicht, dass die Person, die ihn gemacht hat, schlecht ist oder dass man kein Mitgefühl mit ihr hat.
Die Frage ist also, ob die Arbeit der AI-Coding-Tools diesem Standard entsprochen hat. Der Maßstab ist ungefähr: „Ist es besser, dass diese Arbeit in dieser Qualität erledigt wurde, als dass sie gar nicht erledigt wurde?“ Wenn sie die Software verbessert, sollte man weitermachen; wenn sie sie verschlechtert, sollte man aufhören. Ich behaupte nicht, dass das eine besonders raffinierte Definition ist, aber ich halte sie für die richtige.
Wir haben kein Recht, von Tridgell zusätzliche Arbeit zu verlangen, aber wenn es stimmt, gibt es durchaus Raum zu sagen: „Das macht die Situation für die Nutzer schlechter.“
Ehrlich gesagt habe ich noch keine völlig ausgereifte Meinung dazu, wie diese Arbeit zu bewerten ist. Es gab Regressionen, und Tridgell bezeichnete sie als Randfälle, aber ohne mehr Kontext weiß ich nicht, wie ich die Auswirkungen dieser Randfall-Regressionen gegen den Wert potenzieller Sicherheitsfixes abwägen soll.
Manche werden jetzt an „WITHOUT ANY WARRANTY“ denken, aber diese Klausel ist hier irrelevant. Sie ist ein Ausschluss rechtlicher Haftung, nicht ein Ausschluss von handwerklichem Anspruch oder der nicht rechtlichen Erwartung, sein Bestes zu geben. Auch dieser Kommentar wird „WITHOUT ANY WARRANTY“ geliefert, aber wenn ich Fehler mache, kann ich dafür selbstverständlich kritisiert werden.
Der Autor hat es nicht zu kritischer Software gemacht. Wenn du oder jemand anders es benutzt, liegt die Verantwortung beim Nutzer. Wenn die Software nicht wie erwartet funktioniert, kann man sie forken oder ersetzen. Was man nicht tun kann, ist, die Person dazu zu drängen, nach deiner Pfeife zu tanzen.
Kontext für alle, die die ursprünglichen Berichte über die Regression verpasst haben: https://github.com/RsyncProject/rsync/issues/929
Der Issue-Report ist ein Screenshot eines Mastodon-Posts, und danach folgten mehr als 300 streitige Kommentare.
Erklär es nicht, mach einfach weiter wie bisher. Die Leute, die es nicht mögen, werden es weiterhin nicht mögen
Sie haben schon angefangen, es zu hassen, als die Leute aufgehört haben, Assembler zu schreiben, und das wird auch künftig nicht aufhören.