Der Druck
(daniel.haxx.se)- Die Pflege von curl ist zu einer Vollzeitarbeit geworden, in der Gemeinwohl, technische Herausforderung und Qualitätsziele zusammenkommen, und sie bewegt sich seit Jahren bei rund 50 Stunden pro Woche
- curl ist eine Transfer-Bibliothek und ein Tool mit einer Installationsbasis von etwa 30 Milliarden, was den Druck erhöht, dass sich Sicherheitsfehler nicht auf Nutzer ausbreiten dürfen
- Der aktuelle Eingang von Sicherheitsmeldungen liegt bei 4- bis 5-mal dem Niveau von 2024 und beim Doppelten von 2025; im Schnitt kommt mehr als ein Fall pro Tag herein und muss sofort bearbeitet werden
- Zur Sicherheitsarbeit gehören die Verifizierung von Behauptungen, die Bewertung der Schwere, das Schreiben von Patches, die Ermittlung des Einführungszeitpunkts, das Verfassen von Advisorys sowie die Kommunikation mit Forschenden und dem Sicherheitsteam
- Bis zum geplanten Release warten bereits 12 bestätigte Schwachstellen, und unter einem nie dagewesenen Druck werden die Grenzen bei Finanzierung und personeller Unterstützung sichtbar
Verantwortung für curl und langfristige Wartung
- Open-Source-Arbeit geschieht nicht wegen Geld oder eines glamourösen Lebensstils, sondern wegen ihrer gesellschaftlichen Bedeutung, ihres Nutzens für die Allgemeinheit und der technischen Herausforderung, etwas für alle funktionsfähig zu machen
- Die Arbeit an curl ist seit 2019 Vollzeit und umfasst gewöhnlich rund 50 Stunden pro Woche, tagsüber wie spätabends, unter der Woche wie am Wochenende
- Das Ziel von curl ist es, die bestmögliche Transfer-Bibliothek und das bestmögliche Tool zu sein und bei Open-Source-Qualität, -Performance und -Sicherheit zur Spitzengruppe zu gehören
- curl ist kein Ein-Personen-Projekt, und ohne die Teammitglieder gäbe es das heutige curl nicht, aber viele verbinden curl weiterhin stark mit Daniel Stenberg persönlich
- Kritik an curl fühlt sich an wie Kritik an Entscheidungen und Abwägungen, die man selbst unterstützt oder direkt getroffen hat; curl ist zu einem sehr persönlichen Projekt geworden, das das eigene Leben dauerhaft verändert hat
- Ende 2026 feiert das curl-Projekt sein 30-jähriges Jubiläum, und die Zahl der curl-Installationen weltweit wird mit etwa 30 Milliarden angegeben
Wandel im Umfeld von Sicherheitsmeldungen
- In den vergangenen Jahren hat sich das Umfeld für curl-Sicherheitsmeldungen von Beschwerden über dumme LLMs über AI-Slop-Berichte, das Ende des Bug-Bounty-Programms bis hin zu dem seit etwa März 2026 begonnenen hochwertigen Chaos entwickelt
- Jedes Mal, wenn sich große Sicherheitsausfälle bei Internetprodukten, Software-Infrastruktur oder Open Source wiederholen, wächst der Druck durch die Tatsache, dass curl überall steckt und so etwas weder curl noch seinen Nutzern passieren darf
- Das curl-Projekt hat zusätzliche Prüfungen, Tests und Richtlinien eingeführt und damit die Wahrscheinlichkeit schrittweise gesenkt, dass Fehler durchrutschen oder zum Problem werden
Hohes Prüfungsniveau und verbleibendes Risiko
- Nach dem Fall, in dem Mythos beim ersten Scan nur ein Problem mit niedriger Schwere fand, wird immer wieder betont, dass curl zu den am stärksten überprüften, gefuzzten und validierten Codebasen gehört, die man sich vorstellen kann
- Dieser Zustand ist kein Zufall und kein Glück, sondern das Ergebnis jahrzehntelanger beharrlicher Arbeit, Aufmerksamkeit für Details und fortlaufender iterativer Verbesserung
- Viel Review und Validierung bedeuten nicht, dass es keine Bugs oder Sicherheitsprobleme gibt; curl besteht aus Hunderttausenden Zeilen C-Code, der hochgradig paralleles Networking über viele Protokolle, Betriebssysteme und CPU-Architekturen hinweg ausführt
- Jedes entdeckte Problem wird behoben, und der Zyklus aus Fixes und Releases wiederholt sich fortlaufend
- Eine weltweite Installationsbasis von rund 30 Milliarden bedeutet, dass curl wahrscheinlich mehrfach in Smartphones, Tablets, Autos, Fernsehern, Druckern, Spielkonsolen und Küchengeräten enthalten ist
- Projekte, die in der Vergangenheit mit großen Bugs zeitweise die Welt in Aufruhr versetzten, bekamen viel Aufmerksamkeit, und einige erhielten Finanzierung und Personal, um mehrere Vollzeit-Ingenieure einzustellen
Nie dagewesene Menge an Sicherheitsmeldungen
- Der aktuelle Eingang von Sicherheitsmeldungen liegt 4- bis 5-mal höher als 2024 und doppelt so hoch wie 2025; im Durchschnitt geht mehr als eine Meldung pro Tag ein
- Die Qualität der Meldungen ist deutlich höher als früher, und sie sind meist sehr detailliert und lang
- Weil ständig neue Meldungen eingehen, müssen sie möglichst sofort nach Eingang bearbeitet werden; gelingt das nicht annähernd im gleichen Tempo, wächst die Liste potenzieller Sicherheitsprobleme immer weiter an
- Eine unkontrolliert wachsende Liste potenzieller Sicherheitsprobleme ist psychisch belastend
- Der Großteil der Zeit geht derzeit in die Bearbeitung der bei HackerOne gemeldeten Sicherheitsprobleme
- Zu den Hauptaufgaben gehören die Verifizierung von Behauptungen, die Bewertung der Schwere, das Schreiben von Patches, die Ermittlung des Zeitpunkts, an dem ein Bug eingeführt wurde, das Verständnis der Schwachstelle, das Verfassen detaillierter Sicherheits-Advisorys sowie die Kommunikation mit Sicherheitsforschenden und dem curl-Sicherheitsteam
Belastung für Gesundheit und Team
- Zum ersten Mal hat die Ehepartnerin Besorgnis über die Arbeitszeiten und die unausgewogene Work-Life-Situation geäußert, und auch Menschen im Umfeld sorgen sich darum, wie dieser massive Zustrom bewältigt werden soll und ob Burnout droht
- Auch die Sorge um die Teammitglieder ist gewachsen, und möglicherweise muss die Arbeitszeit bald reduziert werden, um wieder etwas Luft zu bekommen
- Die aktuelle Situation bedeutet einen Druck, den weder das curl-Projekt noch die Mitglieder des Sicherheitsteams je zuvor erlebt haben
- Die Bearbeitung von Sicherheitsproblemen hat höchste Priorität und verdrängt praktisch alle anderen Arbeiten am Projekt; aus Verantwortungsgefühl, Gewissen und Stolz auf die Arbeit wird sie nicht ignoriert
- Weil curl weltweit auf Geräten ausgeliefert wird, ist das Pflichtgefühl stark, Sicherheitsprobleme darin auch zu beheben
- Bis zum geplanten Release, obwohl bereits etwa die Hälfte des Release-Zyklus verstrichen ist, gibt es schon 12 bestätigte Schwachstellen, also 12 ausstehende CVE-Veröffentlichungen
- Das ist ein Projektrekord und bedeutet, dass 2026 noch vor der Jahresmitte 30 veröffentlichte CVEs erreicht werden
- Wenn sich dieser Trend fortsetzt, wird die Gesamtzahl der 2026 veröffentlichten curl-CVEs voraussichtlich mindestens doppelt so hoch liegen
Nötige Unterstützung und strukturelle Grenzen
- Kurzfristig ist der Zustand bereits so, dass es für sofortige Hilfe eigentlich zu spät ist, weil schon jetzt zu viel bearbeitet werden muss
- Wenn mehr Unternehmen, die curl oder libcurl in kommerzieller Software und Diensten nutzen und davon abhängen, finanzielle Unterstützung leisten würden, könnten mehr Entwickler bezahlt werden, um die Arbeitslast zu verteilen
- Auch Supportverträge, über die Arbeitgeber die Kosten tragen, sind ein möglicher Unterstützungsweg
- Es gibt bereits Kunden, die auf diese Weise unterstützen, sodass einige Beteiligte Vollzeit an curl arbeiten können
- Allerdings besteht keine große Erwartung, dass sich in diesem Bereich bald substanziell etwas ändert; selbst in dieser beispiellosen Lage und in schwierigeren Phasen wird man den Sturm am Ende vermutlich wieder aus eigener Kraft durchstehen
- Das curl-Projekt gehört keinem Unternehmen und ist auch keiner Dachorganisation unterstellt
- Diese Struktur führt manchmal zu Ressourcenmangel, bietet zugleich aber maximale Freiheit und Flexibilität
- Maßstab für das Handeln des Projekts ist, curl für die Welt und für seine Nutzer so gut wie möglich zu machen
Die positive Seite und der aktuelle Zustand
- Bugs und Probleme zu beheben, ist an sich etwas Gutes, und jedes gemeldete Problem bedeutet letztlich ein behobenes Problem
- Je mehr Meldungen eingehen, desto besser wird curl als Produkt
- Die in den vergangenen Jahren entdeckten curl-Schwachstellen wurden alle mit LOW oder MEDIUM bewertet, und wirklich schwerwiegende Schwachstellen wurden kaum gefunden
- Das heißt nicht, dass nie wieder ein HIGH auftauchen kann, aber zumindest ist das derzeit selten
- Die jüngste curl-CVE mit hoher Schwere war CVE-2023-38545, veröffentlicht im Oktober 2023
- Das curl-Team steht derzeit unter Druck, und Antworten können manchmal langsamer ausfallen
1 Kommentare
Lobste.rs-Kommentare
Ich hoffe, dass Daniel und die anderen diese schwierige Situation ohne größere negative Auswirkungen auf Gesundheit oder Familie gut überstehen.
Ich finde es allerdings ziemlich interessant, wie sich das entwickeln wird. Es ist nicht das erste Mal, dass ein neues automatisiertes Analyseverfahren plötzlich viele Schwachstellen in verschiedenen FOSS-Projekten findet, und im Moment fühlt es sich ähnlich an wie damals, als in den 2010ern Greybox-Fuzzing aufkam. Es scheint drei mögliche Entwicklungen zu geben: A) ein Fuzzer-Szenario, in dem Entwickler LLMs in den Security-Research-Workflow einbauen, die Zahl neuer von LLMs gefundener Schwachstellen stark sinkt und weiterhin Schwachstellen entdeckt werden, an die LLMs nicht herankommen. B) ähnlich wie A, aber nach dem Durchlauf der LLMs kommen Schwachstellenfunde praktisch zum Stillstand — das Szenario „LLMs lösen Security Research“. C) das Szenario „Tony Hoares Rache“, in dem in großen Projekten wie curl weiterhin in hohem Tempo Schwachstellen gefunden werden und die Zahl der Bugs in Projekten mit Hunderttausenden Codezeilen faktisch unendlich ist.
In einem Snapshot einer bestimmten Codebasis kann es nur endlich viele Security-Bugs geben. Wenn der Suchraum für Security-Bugs ausgeschöpft ist, wird die Flut nachlassen, und danach bleiben nur noch nach und nach Bugs übrig, die durch Code-Merges, neue Test-Harnesses oder Modellverbesserungen gefunden werden.
Was bei curl mit dem C-Szenario zusammenhängt: Ich denke, die gefundenen Bugs hatten eine niedrige Schwere, weil die Messlatte bei Security-Tests und klassischen Bug-Finding-Techniken bereits hoch lag. Das zeigt, dass sich kontinuierliche Investitionen in Bug-Finding langfristig weiter auszahlen. Das gilt unabhängig davon, welche Entdeckungsmethode es heute oder in Zukunft gibt.
Um Marcus Hutchins zu zitieren: „Der Engpass war nie das Finden von Bugs, sondern die Entscheidung von Organisationen, nicht in Security Researcher zu investieren.“ LLMs haben diese Investition nur billiger gemacht, und Organisationen hätten schon immer mehr investieren können, um mehr Bugs zu finden. Am Ende ist es eine politische Entscheidung.
Die Unternehmen, die LLM-Technologie bauen, zerstören nicht nur die natürliche Welt, sondern auch die Welt der Software. Da die Hardwarepreise explodieren, ist selbst Personal Computing bedroht, ebenso gutwillige Open-Source-Entwickler, die Dinge einfach bauen, weil sie sie bauen wollen.
Es wirkt interessant, dass es unendliche Mittel dafür zu geben scheint, bestehende Community-getragene Open-Source-Projekte herabzusetzen und kaputtzumachen, aber überhaupt kein Geld, um die Folgen davon aufzufangen.
Ich denke, das beweist, dass Zig recht hatte. Mit von LLMs gefundenen CVEs sollte man sich einfach nicht befassen und sie denen überlassen, die das unbedingt wollen.
Ich weiß, dass das nicht ganz der Kernpunkt ist, aber das Problem bei LLM-CVEs ist, dass wahrscheinlich jeder andere mit demselben Tool genau dieselben Dinge finden kann. Wenn also tatsächlich ein ernstes Problem entdeckt wird, heißt das auch, dass mehr Leute damit etwas Schädliches bauen können.
Das heißt natürlich nicht, dass das in gleicher Weise für die Flut an Low-Severity- oder Non-Security-Issues bei curl gilt. Trotzdem muss man real einschätzen, welche Issues hohe Priorität haben, und dann ist man wieder bei Schritt 1.
Zig ist noch in aktiver Entwicklung, und jedes Mal, wenn Funktionen wie inkrementelle Kompilierung oder asynchrones I/O weiter konkretisiert werden, ist die Wahrscheinlichkeit hoch, dass neue Bugs eingebaut werden, während gleichzeitig Bugs verschwinden, die durch unvollständige frühere Implementierungen entstanden sind.
Wenn in dieser Entwicklungsphase jemand so etwas wie Mythos auf Zig losließe und mit der Haltung käme „findet einfach alle Bugs und macht keine Fehler“, würde das wahrscheinlich eine gewaltige Menge Reports erzeugen, von denen für uns insgesamt praktisch nichts nützlich wäre. Der Hauptwert von Bug-Reports besteht derzeit darin, uns zu signalisieren, dass ein Nutzer in einem bestimmten Use Case blockiert ist, und wenn wir uns entscheiden, das zu priorisieren, können wir diesem Nutzer helfen.
Das wird aber nicht ewig so bleiben. Viele wichtige Compiler-Features werden gerade in Form gebracht, und sobald sie stabilisiert sind, wird das Finden und Beheben aller Bugs oberste Priorität haben. Dann wird die Tatsache, dass ein Bug bekannt ist, unabhängig von der Art seiner Entdeckung wichtig sein — aber dieses Problem werden wir dann angehen.
Bis dahin lautet die Politik schlicht LLM-Verbot.
Ich verstehe das Verbot von LLM-Beiträgen, stimme aber nicht zu. Eine Security-Schwachstelle ist eine Schwachstelle, unabhängig davon, wie sie entdeckt wurde.
Ich denke, Daniels Vorgehen ist das Beste: Bugs beheben, die sich beheben lassen, Nutzer sicherer machen und dabei klar benennen, wie hoch der Preis dafür ist, und um Unterstützung bitten. Wahrscheinlich wird er diesen Beitrag nie lesen, aber ich würde auch unterstützen und empfehlen, die Arbeitsmenge zu begrenzen, um körperliche und mentale Gesundheit an erste Stelle zu setzen. Der größte Teil der Welt wird das verstehen, und nur eine Minderheit wird sich beschweren.
Mir scheint, hier fehlen zwei zentrale Punkte. 1) Weder die LLM-Unternehmen noch Project Zero haben diese Security-Bugs in den Code eingebaut. 2) Das Beheben von Security-Bugs geschieht nicht für LLM-Unternehmen oder Project Zero, sondern für die Nutzer. Wenn Security-Bugs ausgenutzt werden, trifft der Schaden die Nutzer.
Gerade bei von LLMs gefundenen Bugs gibt es bereits Signale, dass andere Leute, die in mehreren Open-Source-Projekten dasselbe LLM verwenden, doppelte Reports einreichen. Deshalb muss man davon ausgehen, dass, wenn Verteidiger die Hände davon lassen, auch Angreifer von durch LLMs gefundenen Bugs erfahren.
„Ich beneide Projekte, die in der Vergangenheit schreckliche Bugs ausgeliefert haben, welche die Welt eine Zeit lang in Brand gesetzt haben. Sie bekamen Aufmerksamkeit, und manche erhielten Finanzierung und finanzielle Schlagkraft, konnten Personal einstellen und mehrere Vollzeit-Ingenieure beschäftigen. Manchmal denke ich, wir wären vielleicht besser dran gewesen, wenn wir auch so etwas gehabt hätten.“
So etwas passiert auch an vielen Arbeitsplätzen. Teams, die scheitern, bekommen mehr Leute, und Teams, die gut funktionieren, müssen mit weniger Leuten mehr Arbeit leisten, gerade weil nichts Schlimmes passiert.
Ich weiß nicht, ob das zu einem Projekt wie curl passt, aber würde ein Feature-Freeze für eine gewisse Zeit helfen, damit man sich nur auf eingehende Bug-/CVE-Reports konzentriert?
Bei einem festen Feature-Set ist die Zahl potenzieller Bugs/CVEs endlich, und während man sie behebt, müsste sie sich doch gegen null bewegen.
Jedenfalls wünsche ich ihnen viel Glück. Es wird keine leichte Zeit sein, so wichtige Software zu warten.
Auf die Zufriedenheit von Entwicklern wirkt das der Reihe nach steigernd, neutral bzw. senkend.
Ein Feature-Freeze ist ein hervorragendes Werkzeug, um ein Release sauber abzuschließen, aber kein gutes Werkzeug, um den Druck für Entwickler zu verringern, die selbstbestimmt an ihrer Roadmap arbeiten.