Innhold Vis
Rsync 3.4.3 – en sikkerhetsrelease som fikser seks CVEer – inneholder hundrevis av commits co-authored av Claude AI. Det ble lagt merke til. Hacker News-tråden tok fyr, og spørsmålene strømmet inn: Er det greit at kritisk infrastruktur skrives med AI? Hvem har egentlig ansvar for koden?
Jeg synes dette er en interessant sak, for den treffer på noe vi ikke har ordentlig tatt stilling til ennå: Hva skjer når AI begynner å co-author kode i prosjekter som har eksistert i nesten 30 år, og som kjører på millioner av servere?
La oss ta det rolig og se på hva som faktisk skjedde – ikke bare reagere på overskriften.
Hva er rsync, og hvorfor bryr folk seg?
Rsync er et filsynkroniseringsverktøy som har eksistert siden 1996. Det er en av de tingene som bare er der – på nesten alle Linux-servere, i backup-systemer, i deployment-pipelines. Sannsynligvis kjører det på infrastruktur du er avhengig av akkurat nå uten at du vet det.
Versjon 3.4.3 ble sluppet 20. mai 2026 og er beskrevet som en «større sikkerhetsutgivelse». Den fikser seks CVEer, inkludert symlink race conditions, heltallsoverflyt i komprimert token-dekoder, og buffer-overflyt i HTTP CONNECT proxy-handler. Ikke trivielle saker. Dette er kode som håndterer filsystemoperasjoner på lavt nivå, og der en feil kan bety datakorrupsjon eller eskalering av rettigheter.
Vedlikeholderen er Andrew Tridgell – mannen som også laget Samba og som har vært sentral i open source-verdenen i tiår. Ikke akkurat en amatør.
Hva inneholder disse Claude-commitsa egentlig?
Her er det viktig å faktisk se på hva commitsa handler om – ikke bare reagere på at de finnes. Jeg sjekket GitHub-repoet, og bildet er ganske annerledes enn overskriften antyder.
De fleste Claude-commitsa gjelder:
- CI-infrastruktur (GitHub Actions, artifact-håndtering)
- Testsuiter og coverage
- Linting av workflow-filer
- Dokumentasjon
Det er altså ikke slik at AI har skrevet kjernelogikken i rsync. Det er snakk om testkode og CI-oppsett – den typen arbeid som er repetitivt og tidkrevende, og der AI faktisk er nyttig. Tridge har co-authored disse commitsa, som betyr at han har gjennomgått og godkjent dem.
Noen av regresjonsfiksingene i selve rsync-koden ser ut til å ha involvert AI-assistanse også, men det er vanskeligere å si nøyaktig hvor grensen går uten å gå gjennom alle commit-meldingene manuelt.
Er dette egentlig et problem?
Hacker News-tråden var delt. Noen mente dette er skremmende for kritisk infrastruktur. Andre pekte på at ansvaret alltid ligger hos den menneskelige revieweren – verktøyet er irrelevant.
Jeg lander nærmere det siste. Spørsmålet er ikke om koden ble skrevet med AI, men om den ble gjennomgått skikkelig. En dårlig commit er en dårlig commit uansett om den kom fra en trøtt utvikler klokken 23 eller fra Claude. En god review fanger feil uansett kilde.
Det som derimot er legitimt å stille spørsmål ved: Noen brukere rapporterer at 3.4.2 og 3.4.3 har introdusert regresjoner som bryter funksjoner som har fungert stabilt siden tidlig på 2000-tallet. Hvis det stemmer, er det et problem – men det er et QA-problem, ikke et AI-problem. Disse versjonene fokuserte på sikkerhetsfikser, og det er kjent at sikkerhetsherding av og til bryter eksisterende oppførsel.
Linux-kjernen har allerede hatt denne diskusjonen
Rsync er ikke det første store open source-prosjektet som møter dette. Linux-kjernen innførte egne regler for AI-assistert koding tidligere i år. Linus Torvalds er ikke prinsipielt mot AI-assistert kode, men krever at det tydelig merkes og gjennomgås på nøyaktig samme måte som all annen kode.
Det interessante er at rsync faktisk merker dette – «Co-Authored-By: claude» i commit-meldingene er transparent. Det er det samme prinsippet som brukes i Claude Code og andre AI-kodeverktøy i dag. Du ser hvem som bidro.
Det som skiller kritisk infrastruktur fra et hobbyprosjekt er ikke om AI er involvert – det er review-prosessen og testdekningen. Og der har rsync, med sine CVE-fikser og regresjonskontroll, i alle fall forsøkt å gjøre jobben.
Hva betyr dette for open source fremover?
Vi er midt i et skifte. AI-verktøy som Claude Code, GitHub Copilot og andre blir en naturlig del av utviklerarbeidsflyten – også for frivillige open source-vedlikeholdere som ofte opererer alene og under tidspress. Tridge har sannsynligvis brukt AI for å håndtere seks CVEer raskere enn han ellers ville klart det.
Det er ikke nødvendigvis galt. Men det setter press på noe som open source-verdenen alltid har slitt med: reviewkapasitet. Når én person vedlikeholder et prosjekt som millioner avhenger av, og AI hjelper ham produsere kode raskere, er spørsmålet om han rekker å gjennomgå alt ordentlig – ikke om AI er et dårlig verktøy.
Den diskusjonen er faktisk viktigere enn «Claude co-authored rsync». Vi har lenge visst at mange kritiske open source-prosjekter er underbemannet og avhengig av enkeltpersoner. AI akselererer produksjonshastigheten uten nødvendigvis å øke reviewkapasiteten tilsvarende.
Transparens er riktig vei
Det jeg synes er bra med dette: Tridge gjemmer det ikke. «Co-Authored-By: claude» i commit-meldingene er akkurat slik det bør være. Hvis du bruker AI til å skrive kode, si det. La reviewer ta stilling med fullt bilde.
Det er vesentlig annerledes enn å sende inn AI-generert kode uten å nevne det – noe som skjer mye mer enn de fleste tror, og som er et langt større problem. Linux-kjernens regler adresserer nettopp dette: AI-assistert kode er greit, men det må merkes.
Rsync 3.4.3 er en sikkerhetsrelease som fikser reelle sårbarheter. Om noen av commitsa ble skrevet med AI-assistanse endrer ikke det faktum at de seks CVEene er patchet og at koden er tilgjengelig for alle å inspisere. Det er open source slik det er ment å fungere.
Spørsmålet vi bør stille er ikke «er AI involvert?» men «er reviewprosessen god nok?» Og den diskusjonen bør vi ta for alle store open source-prosjekter – med eller uten AI.
