Als je ooit remote bestanden hebt geback-upt, heb je vrijwel zeker een systeem gebruikt dat werkt met rsync. Het is een van de meest gebruikte tools in de Unix-wereld, draaiend op servers, back-upsystemen en in wetenschappelijke computerclusters. Het is infrastructuur in de minst eervolle zin: onzichtbaar als het werkt, catastrofaal als het niet werkt.
Rsync, doorgaans beschouwd als een zeer stabiel softwareproject, kwam onlangs onder vuur te liggen na een aantal releases die hadden geleid tot een stroom aan bugs en klachten. Deze waren deels gericht op de inhoud, maar misschien nog wel meer op de nieuwe manier waarop ontwikkelaar Andrew Tridgell het project doorontwikkelt: met AI.
Alle zeilen bijzetten
In een Medium-post bespreekt Tridgell de achtergrond van dit verhaal. Hij kreeg te maken met een toenemende stroom meldingen van security vulnerabilities. Veel daarvan waren AI-gegenereerd, al zegt hij dat “er enkele opmerkelijke zijn met zeer zorgvuldige en hoogwaardige handmatige analyses.” Dit is duidelijk geen compliment aan de AI-gegenereerde meldingen, maar het lijkt er wel op dat Claude Mythos en de nieuwste modellen van andere bedrijven goed in staat zijn kwetsbaarheden in software te ontdekken. Veel van de meldingen die Tridgell ontving, betroffen echte exploits in de rsync-code, zegt hij.
Tridgell stond (staat) onder druk en realiseerde zich dat de verdediging van rsync – testdekking, pipelines, beveiligingsscans – opgeschroefd moest worden. Hij is overigens geen AI-voorstander per se. Zijn motivatie om het te gebruiken is nogal pragmatisch:
Andrew Tridgell: “Ik ben met pensioen (al zal mijn vrouw dat misschien betwisten!) en ik ga liever zeilen dan aan rsync-veiligheidslekken werken, dus ik heb verschillende AI-tools ingeschakeld om te helpen met wat nodig is.”
De regressies, die volgens Tridgell inderdaad in die specifieke release (3.4.3) zijn opgetreden, zorgden voor veel aandacht voor het project en zijn onderhouder. Eén gebruiker ging zelfs zo ver om een GitHub-issue aan te maken: “Please Do Not Vibe Fuck Up This Software.” Het sentiment over vibe coding online is grotendeels negatief, maar Tridgell verdedigt zijn handelen als weloverwogen:
Andrew Tridgell: “Ik heb bewust geprobeerd om voor die release de nadruk te leggen op het oplossen van beveiligingsproblemen, en er waren enkele geldige (maar ongebruikelijke) use cases die daardoor geraakt werden. Geen van die gevallen werd gedekt door de bestaande rsync-testsuite […]”
Wat zijn manieren waarop AI-gegenereerde code regressies kan veroorzaken in een project als dit, geleid door een ontwikkelaar met veertig jaar ervaring en een uitgebreide testsuite? In één voorbeeld uit een Hacker News-thread merkte een bijdrager een commit op die de volgende wijziging introduceerde:
- if (!ptr)
- ptr = malloc(num * size);
- else if (ptr == do_calloc)
+ if (!ptr || ptr == do_calloc)
ptr = calloc(num, size);De inmiddels teruggedraaide wijziging, geschreven met Claude, dwingt stilletjes alle geheugentoewijzingen om calloc te gebruiken (een subtielere en duurdere bewerking) in plaats van alleen die welke “zeroed” geheugen vereisen. “Voor grote en recursieve toewijzingen wordt dit een aanzienlijke kostenpost,” schrijft gebruiker GodelNumbering.
De 3.4.3-release, snel uitgebracht om beveiligingsproblemen aan te pakken, introduceerde regressies zoals deze die legitieme use cases braken die niet door de bestaande testsuite werden gedekt. Omdat het werd gepresenteerd als een security patch, verspreidde het zich snel via geautomatiseerde upgrades. Dit had direct effect op echte data over de hele wereld.
Reilen en zeilen
Rsync wordt feitelijk door één persoon onderhouden. Tridgell is met pensioen. Als hij liever zou gaan zeilen, waarom doet hij dat dan niet? Hij wordt niet voor zijn werk betaald, hoe onterecht dat ook is. Door zijn betrokkenheid bij “zijn” project voelde hij zich genoodzaakt te kiezen. Snel patchen, met risico op regressies. Of zorgvuldig patchen, waardoor gebruikers langer kwetsbaar blijven.
Waar de taak voorheen te gigantisch zou zijn geweest voor één persoon om zelfs maar aan te beginnen, bood AI iets wat op een uitweg uit dit dilemma leek: snel patchen én zelfs de testdekking vergroten. En omdat AI-tools zowel onderdeel van het probleem als van de oplossing waren, ging het omringende debat al snel over AI versus anti-AI. Maar dit verhult een dieper probleem, zoals een commentator op de Medium-post opmerkt:
Reactie op Medium: “Gefeliciteerd. Je bent erin geslaagd om Claude en Vibe Coding te verexcuseren voor de puinhoop. Blijkt dat het probleem wanbeheer van het project was.”
Onzekerheid in twee richtingen
Redelijke mensen kunnen langs elkaar heen praten wanneer de situatie in twee richtingen tegelijk werkelijk onzeker is, en dat is het geval bij rsync.
Hoe ernstig zijn de kwetsbaarheden echt?
We weten niet hoe ernstig de kwetsbaarheden in de praktijk daadwerkelijk zijn. Een comment onder Tridgell’s post stelt: “De meeste van deze CVE’s zullen volkomen irrelevant zijn voor de dagelijkse realiteit van gebruikers.” Maar als jij degene bent die het project onderhoudt, geconfronteerd met duizend CVE’s, ben je dan nog zo zeker van je zaak?
Wat is het risico van snelheid?
Tegelijkertijd brengt het op snelheid releasen van AI-ondersteunde refactors ook risico en onzekerheid met zich mee. Zeker bij software die zo breed wordt gebruikt als rsync. Regressies in dit soort software zullen vrijwel zeker schade aan gebruikers veroorzaken. Wat is de kans, hoeveel mensen worden getroffen, en hoe groot is de schade?
We kunnen zeker iets zeggen over beide paden, en ze kunnen zelfs tegelijk waar zijn. Geen van deze observaties wint de discussie. Deze onzekerheid is niet de schuld van Tridgell, of van enige andere open source-maintainer, of ze nu AI gebruiken of niet. Onzekerheid en risico zijn intrinsiek aan softwareontwikkeling op snelheid. Als we een meetlat tevoorschijn konden halen en de optie met het laagste risico konden aanwijzen, zouden we dat al lang aan het doen zijn. Dit is waarom Quality Assurance bestaat, en waarom individuele bijdragers over het algemeen niet aansprakelijk zijn wanneer er wel schade optreedt.
Foto: Evan Smogor via Unsplash
Wind uit de zeilen
Enige bescheidenheid is op zijn plaats wanneer wij niet degene zijn die de beslissing nemen; die de code goedkeuren, de release uitbrengen, wakker worden met een vloed aan regressiemeldingen en persoonlijke bedreigingen. Maar zou een project zo gigantisch belangrijk als rsync moeten rusten op de schouders van een handjevol ontwikkelaars, hoe bekwaam ook?
Dit is geen nieuw probleem. Open source software die commerciële systemen ondersteunt, is altijd onevenredig onderhouden door onbetaalde individuen die in het openbaar werken, zonder de organisatorische structuur die normaal gesproken bestaat om risico’s te beheersen.
Waarom QA-processen en releasebeheer bestaan
We kunnen onzekerheid niet wegnemen, maar we kunnen er weloverwogen beslissingen over nemen. Zodat zij die hun pensioen hebben verdiend kunnen gaan zeilen, als dat is wat ze liever zouden doen.
