// La Prima Pagina
Sezione 00. Una non-falla in cima alla classificaApro Hacker News. In cima c'è rsync, sotto un titolo poco diplomatico: "Please Do Not Vibe Fuck Up This Software". 391 punti, 324 commenti. Più in basso il gemello, "Rsync 3.4.3 has hundreds of Claude commits": altri 112 punti, 79 commenti. In totale, ~503 punti e ~403 commenti in poche ore.
Al centro c'è Andrew Tridgell. Sì, quel Tridgell: quello che ha inventato l'algoritmo rsync durante un dottorato, quello che ha reverse-engineerato il protocollo di BitKeeper nella vicenda da cui è poi nato Git, quello che ha scritto metà della roba che gira sulla tua macchina senza che tu lo sappia (Samba, tanto per dirne una). Da quando è tornato a metterci mano, committa con Claude come co-autore. Su 31 commit recenti, 28 firmati "tridge and claude": il 90%. Tre righe di metadati in un commit, e parte la discussione.
Intanto, regressioni nelle 3.4.2 e 3.4.3: backup incrementali che si rompono, carico CPU anomalo, downstream (Timeshift, Void) che aprono issue. Da qui la conclusione diffusa: "rsync è vibe-coded, siamo finiti."
C'è un solo dettaglio, e su quel dettaglio si regge tutto:
Nessuna di quelle regressioni è una CVE. Sono bug funzionali, non buchi di sicurezza. La gravità dell'evento che ha riempito quei due thread, misurata con lo stesso metro che usiamo per tutto il resto (CVSS), è zero. Tienilo lì: tutto quello che segue gira intorno a questo numero.
La domanda non è "l'AI fa bene o male al codice". Quella è materia da commenti, non analisi. La domanda che mi interessa è un'altra:
L'attenzione su un errore è proporzionale al danno tecnico che quell'errore fa davvero? Se sì, i numeri si allineano. Se no, abbiamo misurato qualcosa di preciso: che l'attenzione non segue necessariamente la gravità tecnica.
// I Dati, Verificati
Sezione 01. Niente aggettivi, solo conteggiNiente opinioni, per un po'. Solo numeri, raccolti il 31 maggio 2026 da fonti interrogabili: GitHub API per il progetto, NVD per le vulnerabilità, Hacker News Algolia API per l'engagement. Gli endpoint esatti sono in fondo, così chiunque può rifare i conti.
Il progetto rsync
| Metrica | Valore | Fonte |
|---|---|---|
| Prima release | 19 giugno 1996 | TR-CS-96-05, ANU |
| Età del codice | ≈ 30 anni | (29,95 al mag 2026) |
| Contributi attribuiti (≈ commit, master) | ≈ 9.549 | GitHub API |
| Contributori (identità distinte) | ≈ 177 | GitHub API |
| Top contributor (W. Davison, 2002–2024) | ~4.822 commit | GitHub API |
| Commit recenti co-firmati con Claude | 28 / 31 (~90%) | commit log, mag 2026 |
Un dettaglio sul conteggio, perché il numero va preso per quello che è: 9.549 è la somma del campo contributions restituito dall'API GitHub su tutte le identità del ramo master. È il totale dei contributi attribuiti, che approssima i commit ma non è garantito coincidere col conteggio esatto del repository: può escludere commit non collegati a un'identità o aggregare più email della stessa persona (Davison ha due handle). Siamo comunque nell'ordine delle 9–10 mila unità, e nessuna delle metriche che seguono cambia se il numero vero è 9.200 o 9.800.
Le CVE
Qui c'è un'ambiguità onesta da dichiarare subito: il conteggio esatto delle CVE di rsync dipende da come conti. I database usano namespace frammentati (andrew_tridgell:rsync, samba:rsync, rsync:rsync), quindi una stessa query dà numeri diversi. La ricerca per parola chiave su NVD restituisce 69 risultati (ma include software terzi che menzionano rsync); il match per CPE stretto ne dà pochissimi. Una stima difendibile, attribuibile a rsync il software, è ~25–30 CVE in 30 anni, di cui una manciata (~5–8) di classe critica/RCE.
| CVE | Anno | CVSS | Tipo |
|---|---|---|---|
| CVE-2024-12084 | 2024 | 9.8 | Heap overflow → RCE (batch gen 2025) |
| CVE-2007-6200 | 2007 | 10.0 | Bypass access control via symlink |
| CVE-2007-6199 | 2007 | 9.3 | Symlink in daemon scrivibile |
| CVE-2003-0962 | 2003 | n/d | Heap overflow → RCE |
Nota sui punteggi: le CVE del 2007 usano CVSS v2 (CVE-2007-6200 = 10.0, vettore AV:N/AC:L/Au:N/C:C/I:C/A:C, fonte primaria NVD), mentre CVE-2024-12084 = 9.8 è CVSS v3.1. Le due versioni non sono direttamente confrontabili; per il ragionamento conta solo l'ordine di grandezza, e sono tutte vulnerabilità gravi.
Il punto chiave per tutto ciò che segue: l'evento che ha scatenato Hacker News non è in questa tabella. Non c'è. Non gli è stata assegnata alcuna CVE. La sua gravità di sicurezza misurata è 0.
I thread di confronto
Per calibrare cosa significhi "grave" servono i casi-limite veri, le vulnerabilità che hanno davvero terrorizzato l'industria, col loro engagement sul thread di disclosure principale. Numeri presi uno a uno dall'Algolia API, con l'ID del thread:
| Caso | CVE | CVSS | Punti HN | Commenti HN |
|---|---|---|---|---|
| xz-utils backdoor | CVE-2024-3094 | 10.0 | 4.549 | 1.849 |
| Heartbleed | CVE-2014-0160 | ~7.5 | 1.768 | 528 |
| Log4Shell | CVE-2021-44228 | 10.0 | 1.385 | 503 |
| rsync / Claude | (nessuna) | ≈ 0 | ~503 | ~403 |
Engagement grezzo su Hacker News. xz-utils domina, ma rsync (CVSS ~0) sta nello stesso ordine di grandezza di Heartbleed e Log4Shell per commenti. Per rsync, punti = somma dei due thread.
Già a occhio qualcosa stona: una non-vulnerabilità ha generato l'80% dei commenti di Log4Shell (403 contro 503) e i tre quarti di quelli di Heartbleed (528), pur avendo gravità di sicurezza zero. Ma "a occhio" non basta. Vediamo se i numeri confermano l'impressione.
// Metrica 1: Densità Storica di Vulnerabilità
Sezione 02. CVE per commit, non "tasso di errore"Definiamo la densità di vulnerabilità come rapporto tra CVE e volume di lavoro prodotto. Un avvertimento sul nome, perché conta: questo non è un "tasso di errore" in senso stretto. Una CVE può nascere da più commit, da una feature intera o da codice scritto anni prima, quindi non esiste una corrispondenza pulita uno-a-uno tra vulnerabilità e commit. È un rapporto CVE/commit, una densità, e la chiamo per quello che è:
Con tutte le CVE (prendiamo ~30, generosi) sui 9.549 commit:
Se restringiamo alle sole critiche/RCE (~6):
In pratica significa una CVE critica ogni 1.592 commit attribuiti (1 / 0,00063). È una densità osservata, non una garanzia sul singolo commit: non significa che il 99,94% dei commit sia "sicuro", perché una CVE può dipendere da più commit o da codice scritto anni prima. Resta comunque un tasso bassissimo, su un software che regge praticamente ogni sistema di backup del pianeta: NAS, mirror di distribuzioni, server personali.
// Metrica 2: Indice di Indignazione
Sezione 03. Commenti per unità di gravità realeTrasformiamo il rumore in una frazione. Quanta discussione genera un caso per unità di gravità tecnica reale? CVSS come proxy della gravità, commenti come proxy dell'attenzione:
| Caso | Commenti | CVSS | I = commenti / punto CVSS |
|---|---|---|---|
| xz-utils | 1.849 | 10.0 | 184,9 |
| Heartbleed | 528 | 7.5 | 70,4 |
| Log4Shell | 503 | 10.0 | 50,3 |
| rsync / Claude | 403 | ≈ 0 | non def. (→ ∞) |
Qui salta fuori un caso limite: per rsync il denominatore è zero. L'indice è formalmente non definito, e tende all'infinito se assumiamo CVSS→0⁺. In pratica, 403 commenti su una gravità di sicurezza nulla. Il rapporto attenzione/impatto non è nemmeno confrontabile con gli altri casi, perché il denominatore tende a zero e qualsiasi numeratore positivo lo manda all'infinito.
// Metrica 3: La Gravità Implicita
Sezione 04. Che voto avrebbe dato la folla, se fosse stata coerentePossiamo ribaltare il ragionamento. Tra le vulnerabilità vere, qual è il "tasso di cambio" medio tra gravità e commenti?
Un avvertimento prima di proseguire: è una metrica euristica costruita su tre soli eventi estremi, non una stima statistica dell'intero ecosistema di Hacker News. Serve a dare un ordine di grandezza, non è una legge.
Ora invertiamo. Dati i ~403 commenti di rsync, quale gravità avrebbe dovuto avere per giustificarli, al tasso di cambio del mercato?
La folla si è comportata come se rsync avesse una vulnerabilità di gravità ~4/10. La gravità misurata è 0/10. Lo scarto tra l'attenzione espressa e la sostanza tecnica equivale a circa 4 punti CVSS nella metrica proposta, a fronte di una gravità reale pari a zero.
Nell'economia dell'attenzione, la narrativa può contare più della severità tecnica. "L'autore di rsync usa l'AI" è un titolo che si commenta da solo. "Heap overflow nel parsing di s2length" è soltanto la cosa che può davvero aprire una shell sulla macchina. In questo caso i commenti sembrano seguire più il tema della discussione che la gravità tecnica dell'evento.
// Metrica 4: Probabilità per Singolo Commit
Sezione 05. Una frazione minuscola del lavoroMettiamoci nei panni del maintainer. Qual è la probabilità che un suo commit qualsiasi introduca un disastro? Con ~6 errori critici distribuiti su ~9.549 commit in 30 anni (semplificando: imputiamo ogni vulnerabilità a un singolo commit, un'approssimazione generosa verso l'accusa):
Circa 6 commit su diecimila. E ricordiamo che l'evento di maggio 2026 non rientra nemmeno nel numeratore: è una regressione funzionale, non una vulnerabilità. Se contiamo anche quella manciata di regressioni memorabili come "errori gravi" (diciamo ~16 episodi in 30 anni):
In entrambi i casi siamo abbondantemente sotto lo 0,2% per commit. La domanda diventa difficile da evitare: stiamo giudicando un ingegnere, quello che ha inventato l'algoritmo che usiamo tutti, per una frazione minuscola degli esiti osservabili associati ai suoi contributi?
// La Tesi, in una Riga
Sezione 06. Quello che abbiamo misuratoNon sto sostenendo che usare un LLM nel codice sia una buona idea. La preoccupazione per un LLM che mette le mani su infrastruttura critica è legittima, e se domani salta fuori una CVE da quell'ondata di commit la tesi cade: il denominatore di I smette di essere zero e l'analisi va rifatta. Ma finché quel numero resta zero, quello che misuriamo non è un problema di sicurezza: è uno scarto tra l'attenzione ricevuta e la gravità tecnica dell'evento.
Gravità tecnica (CVSS) contro attenzione (commenti HN). I tre casi reali stanno a destra, dove la gravità è alta. rsync è il punto rosso a CVSS 0: nello stesso ordine di grandezza di Log4Shell e Heartbleed per commenti, con gravità di sicurezza nulla.
"Un evento senza impatto di sicurezza documentato ha generato un'attenzione comparabile a vulnerabilità che hanno coinvolto milioni di sistemi. Se questo sia razionale, lo decida chi legge."
Su Hacker News si discute spesso di qualità del software. Più di rado si prova a misurare il rapporto tra il contributo complessivo e il singolo errore.
// Limiti e Onestà Metodologica
Sezione 07. Dove scricchiolaUn pezzo che si vanta di essere rigoroso deve mostrare da dove perde acqua. Eccolo. Niente di tutto questo ribalta la conclusione: muove i decimali, non la direzione. Se vuoi smontarmi, parti da qui, non dai commenti.
1. CVSS come proxy di gravità comprime impatto, sfruttabilità e diffusione in un solo numero. È imperfetto, ma è lo standard condiviso, e meglio di un aggettivo.
2. Conteggio CVE ambiguo: i namespace frammentati fanno oscillare il totale tra ~20 e ~69 a seconda della query. Ho usato una stima conservativa (~30); cambiarla del ±50% non sposta gli ordini di grandezza.
3. CVSS di Heartbleed: CVE-2014-0160 è antecedente al CVSS v3.1; NVD ne riporta ufficialmente solo il v2 (base 5.0). Il 7.5 che uso è la stima v3 comunemente citata. Anche con 5.0, l'indice di Heartbleed salirebbe a 105,6 e non cambierebbe la tesi.
4. Punti e commenti HN sono uno snapshot e dipendono dall'algoritmo di ranking, dal fuso orario, dalla fortuna. Confronto thread di disclosure principali, non l'intera copertura.
5. Commit ≠ righe ≠ rischio. Un commit di un carattere e uno che riscrive il protocollo pesano uguale nel conteggio. È un proxy grezzo del "volume di lavoro".
6. "Gravità ≈ 0" per rsync/Claude è vero al momento. Nessuna CVE è stata attribuita all'ondata di commit AI. Se ne emergesse una, l'analisi va rifatta. È il punto: la tesi è falsificabile.
// Fonti dei Dati
Sezione 08. Tutto verificabile, tutto datato 2026-05-31Progetto rsync (GitHub API)
- Repository: github.com/RsyncProject/rsync
- Commit totali e contributori (somma del campo
contributions, ~9.549 su ~177 identità): api.github.com/repos/RsyncProject/rsync/contributors?per_page=100&anon=true - Commit recenti co-firmati "tridge and claude" (28/31): github.com/RsyncProject/rsync/commits/master/
Storia e prima release
- A. Tridgell, P. Mackerras, The rsync algorithm, Technical Report TR-CS-96-05, Australian National University, giugno 1996.
- Wikipedia, rsync: prima release 19 giugno 1996; W. Davison maintainer dal 2002; rientro di Tridgell nello sviluppo (aprile 2024).
Vulnerabilità (NVD + CERT/CC)
- NVD, ricerca per parola chiave (69 risultati, include software terzi): services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=rsync
- CERT/CC VU#952657, batch di 6 CVE rsync (gennaio 2025), tra cui CVE-2024-12084 (CVSS 9.8): kb.cert.org/vuls/id/952657
- CVSS dei casi di confronto da NVD: CVE-2024-3094 = 10.0; CVE-2021-44228 = 10.0; CVE-2014-0160 = 5.0 (v2) / ~7.5 (stima v3).
Engagement Hacker News (Algolia API: hn.algolia.com/api/v1/items/<id>)
- rsync: "Please Do Not Vibe Fuck Up This Software" (391 pt, 324 cmt), item 48342705
- rsync: "Rsync 3.4.3 has hundreds of Claude commits" (112 pt, 79 cmt), item 48334021
- xz-utils: "Backdoor in upstream xz/liblzma leading to SSH server compromise" (4.549 pt, 1.849 cmt, 2024-03-29), item 39865810
- Heartbleed: "The Heartbleed Bug" (1.768 pt, 528 cmt, 2014-04-07), item 7548991
- Log4Shell: "Log4j RCE Found" (1.385 pt, 503 cmt, 2021-12-09), item 29504755