rsync co-firmato con Claude diventa il caso che spacca Hacker News: la gravità reale è zero

La vetta di Hacker News di fine maggio ospita due thread su rsync co-firmato con Claude di Anthropic, per un totale di oltre 500 punti e circa 403 commenti in poche ore. I titoli sono incendiari, le diagnosi pure: “rsync è vibe-coded, siamo finiti”, “Please Do Not Vibe Fuck Up This Software”. Al centro c’è Andrew Tridgell, l’autore originale dell’algoritmo, che da quando è tornato a lavorare sul progetto firma 28 commit su 31 come “tridge and claude”: il 90% del lavoro recente è collaborativo con l’LLM di Anthropic.

Il dato che cambia il senso di tutta la discussione è uno solo. Nessuna delle regressioni segnalate ha ricevuto una CVE. Sono bug funzionali, non vulnerabilità di sicurezza: backup incrementali che si rompono, carico CPU anomalo, qualche issue aperta dai downstream Timeshift e Void Linux. Misurata con il metro che usa il resto dell’industria, il punteggio CVSS, la gravità di sicurezza di questo evento è esattamente zero. Tutto quello che segue ruota intorno a quel numero.

Il rumore corre più della gravità

I numeri sono raccolti da fonti interrogabili: GitHub API per il progetto, NVD per le vulnerabilità, Algolia API di Hacker News per l’engagement. Rsync ha circa 30 anni, 9.549 contributi attribuiti, 177 contributori distinti. Davison resta il top contributor con 4.822 commit fra 2002 e 2024. Il conteggio delle CVE oscilla a seconda del namespace usato (rsync, samba:rsync, andrew_tridgell:rsync), una stima difendibile parla di 25-30 vulnerabilità in 30 anni, di cui 5-8 di classe critica. La più recente seria è CVE-2024-12084, heap overflow con CVSS 9.8 documentato dal CERT/CC nel gennaio 2025.

Per calibrare cosa significhi “grave” servono i casi-limite. La backdoor di xz-utils del 2024 (CVE-2024-3094, CVSS 10.0) ha collezionato 4.549 punti e 1.849 commenti sul thread principale di Hacker News. Heartbleed (CVE-2014-0160) ne aveva avuti 1.768 e 528. Log4Shell (CVE-2021-44228, CVSS 10.0) si era fermata a 1.385 punti e 503 commenti. Rsync co-firmato con Claude, gravità di sicurezza zero, sta a 503 punti e 403 commenti: lo stesso ordine di grandezza di vulnerabilità che hanno coinvolto milioni di sistemi. L’80% dei commenti di Log4Shell, i tre quarti di quelli di Heartbleed.

Se trasformiamo il rumore in una frazione, commenti per punto CVSS, i tre casi reali danno indici fra 50 e 185. Per il caso rsync il denominatore tende a zero, e l’indice esplode. L’attenzione collettiva non segue la gravità tecnica, segue la narrativa: “l’autore di rsync usa l’AI” è un titolo che si commenta da solo, “heap overflow nel parsing di s2length” no, anche se è la cosa che apre davvero una shell sulla macchina.

Lo scarto fra gravità reale e gravità percepita

Ribaltando il ragionamento si ottiene un dato ancora più nitido. Il “tasso di cambio” medio fra commenti e CVSS sulle tre vere vulnerabilità è circa 102 commenti per punto. Con 403 commenti, il caso rsync avrebbe dovuto valere una vulnerabilità di gravità 3,95 su 10 per giustificare la sua presenza nel ranking. La gravità misurata è 0. Quattro punti CVSS di distanza fra l’attenzione espressa e la sostanza tecnica.

La densità storica di vulnerabilità di rsync racconta la stessa storia da un’altra angolazione. Con 30 CVE distribuite su 9.549 commit otteniamo lo 0,31%. Restringendo alle sole critiche, lo 0,063%, ovvero una CVE critica ogni 1.592 commit. È un proxy grezzo del “volume di lavoro” e non implica che il 99,94% dei singoli commit sia sicuro, perché una vulnerabilità può dipendere da più commit nel tempo. Resta comunque un tasso bassissimo per un software che gira praticamente sotto a ogni sistema di backup del pianeta: NAS, mirror di distribuzioni Linux, server domestici, datacenter.

La preoccupazione per un LLM che mette le mani su infrastruttura critica resta legittima, e se da quei commit emergerà una CVE l’analisi va rifatta. Ma finché quel numero resta zero la storia non è “l’AI ha rotto rsync”: la storia è che una comunità tecnica considerata esigente ha generato un volume di discussione paragonabile a quello delle peggiori vulnerabilità dell’ultimo decennio per un evento che dal lato sicurezza non esiste.

Cosa dice questo numero al decision-maker

Per chi valuta l’adozione di assistenti AI nello sviluppo enterprise il caso rsync è un test di lettura. Le decisioni di governance sul codice generato da LLM non possono essere informate dal sentiment di un thread, perché il sentiment in questo momento sovrastima il rischio reale di un fattore difficile da calcolare ma evidentemente grande. I criteri vanno tarati sui dati: tasso di regressioni, copertura dei test, presenza di CVE attribuite a commit assistiti, percentuale di accettazione delle proposte. Non sul rumore.

Il caso ha però un secondo livello. L’attribuzione esplicita di Tridgell, “co-authored by Claude” nei metadati dei commit, è una scelta di trasparenza che spinge la discussione fuori dalla cantina dove sarebbe rimasta a tempo indefinito. Senza quella riga di metadati, le stesse regressioni della 3.4.2 e 3.4.3 sarebbero state archiviate come bug ordinari di un progetto trentennale, di cui esistono già una manciata di episodi memorabili. La trasparenza ha un costo di attenzione, e Tridgell lo sta pagando. Pretendere meno trasparenza dagli sviluppatori che usano LLM significa preferire l’opacità al rumore, e di solito non è una buona idea.

Il punto utile non è “Claude scrive bene o male”. Il punto utile è che la comunità Hacker News ha appena fornito una calibrazione pubblica della propria asimmetria fra attenzione e merito tecnico: 403 commenti per zero CVSS, contro 503 commenti per CVSS 10. Chiunque debba prendere decisioni sull’AI dentro un’organizzazione farebbe bene a tenere quella calibrazione presente prima di trattare l’opinione del thread del giorno come un segnale.