Linus Torvalds sbotta: "questo è inaccettabile" e sospende un account

All’alba del ciclo di sviluppo del kernel Linux 6.16, una vicenda insolita ha agitato la comunità open source. Linus Torvalds ha pubblicamente accusato un manutentore veterano di aver introdotto migliaia di commit falsi, facendo sembrare che li avesse scritti e approvati personalmente. Sebbene le indagini in corso stiano suggerendo che si sia trattato di un incidente legato a un errato scripting con Git, l’episodio solleva interrogativi importanti su fiducia, sicurezza e processi nello sviluppo collaborativo.

Il caso del kernel Linux 6.16: migliaia di commit alterati con metadati falsi

La merge window è un periodo di circa due settimane che inizia subito dopo il rilascio di una nuova versione stabile del kernel Linux (abbiamo infatti parlato, di recente, del lancio di Linux 6.15). Durante questa finestra temporale, Torvalds accetta nuove funzionalità, modifiche importanti e aggiornamenti dei sottosistemi dai maintainer ufficiali, integrandoli nel ramo principale (mainline).

È la fase più attiva e delicata dello sviluppo, perché una volta superata la merge window si entra nella “fase di stabilizzazione”: qui si accettano solo correzioni di bug e patch minori fino al rilascio della versione successiva.

Proprio nel weekend di apertura della merge window per Linux 6.16, Torvalds ha scoperto un’anomalia nel ramo Git mantenuto da Kees Cook (area sicurezza e mitigazioni): oltre 6.000 commit erano stati riscritti, e 330 merge commit risultavano attribuiti falsamente a Torvalds stesso, con metadati ingannevoli.

La reazione del “re pinguino” è stata furiosa. Ecco un estratto delle sue parole:

Hai modificato in modo malevolo il tuo albero. Ci sono commit completamente assurdi. […] Questo commit dichiara di essere mio, ma non lo è affatto. […] Questa non può essere una svista. È inaccettabile! (Linus Torvalds).

L’accusa era durissima: non un semplice errore, ma un comportamento definito “malevolo”. Così, su disposizione dello stesso Torvalds, l’account di Kees ha subìto una temporanea disabilitazione in attesa di spiegazioni.

La causa: scripting difettoso e strumenti pericolosi se usati male

A un’analisi più approfondita, l’origine del problema sembra ricondursi a una catena di strumenti e script automatizzati, usati per gestire le patch e riscrivere la storia del repository.

Sembra che, in seguito a una ricostruzione della tree da un backup dopo un possibile guasto hardware, alcuni script abbiano rigenerato la cronologia alterando metadati critici: committer name, commit ID, timestamp. Una catena di eventi che ha portato alla generazione di una nuova cronologia Git in cui vecchi commit apparivano come nuovi, e — peggio ancora — attribuiti a Torvalds stesso.

Cook ha confermato la presenza di commit anomali nel suo repository e ha collaborato per ricostruire il lavoro da una copia attendibile.

Perché è grave? La fiducia nella catena di approvazione

Nel kernel Linux non esiste una piattaforma centralizzata con pull request in stile GitHub: tutto si basa su mailing list, patch, hash Git e fiducia. Se una tree presenta migliaia di commit riscritti e metadati alterati, si incrina la trasparenza della catena.

L’uso di strumenti avanzati, seppur legittimo, richiede estrema cautela: i metadati dei commit servono per stabilire chi sono gli autori di modifiche sul codice e risalire alle responsabilità. Gli hash Git sono a loro volta fondamentali per l’integrità: se cambiano, il sistema non può più garantire che una patch sia “quella originale”.

Commit, tree e maintainer: come funziona lo sviluppo del kernel

Ciascun sottosistema del kernel (driver, networking, sicurezza,…) ha uno o più sviluppatori responsabili, chiamati maintainer: ricevono patch via mailing list, le testano, le raccolgono in rami Git e infine le propongono a Linus Torvalds per l’inclusione nel ramo principale.

Ogni commit rappresenta una modifica (o un insieme di modifiche) al codice sorgente, accompagnata da metadati come autore, committer, data e messaggio descrittivo. Ogni commit è identificato da un hash univoco (SHA-1).

All’interno di Git, inoltre, il tree rappresenta la struttura delle directory e dei file in uno specifico stato del repository. In senso più generale, una tree è la collezione dei commit e delle modifiche che un maintainer propone al fine della loro integrazione nel codice principale.

Come già evidenziato, questo processo distribuito si basa su una fiducia reciproca e sul corretto uso degli strumenti Git. Ogni maintainer dispone di un account su kernel.org, da cui Torvalds estrae le modifiche per integrarle nel kernel.

Riflessioni e lezioni per l’open source

L’incidente che ha fatto, di nuovo, infuriare Linus Torvalds ha riacceso il dibattito su come rafforzare la sicurezza e la responsabilità nello sviluppo open source.

Git è uno strumento potente, ma anche pericoloso se usato con script personalizzati. Tool come git-filter-repo possono “riplasmare la cronologia” con un solo comando.

Anche in assenza di attacchi esterni, errori umani o automatismi mal configurati possono compromettere la fiducia nella filiera del software.