Backdoor governative sul codice Linux? Linus Torvalds è un firewall umano.

La frase “Linus Torvalds è un firewall umano” nasce come battuta, ma descrive bene una realtà: nel kernel Linux esiste un filtro umano severissimo, capace di alzare polvere anche su cambi “minori”. Se per una questione tutto sommato marginale riesce a sollevare un vespaio e a fermare una patch, figuriamoci che cosa accadrebbe davanti a un tentativo di introdurre codice malevolo o una backdoor.

È importante chiarirlo subito: qui non stiamo dicendo che ci siano backdoor. Anzi, nell’episodio recente che ha riacceso la discussione non c’è nulla di simile. C’è un rifiuto netto di una pull request giudicata “spazzatura”, inviata tardi nella merge window e contenente un helper generico che, in estrema sintesi, univa due valori a 16 bit in un 32 bit. Nessun complotto: cattiva tempistica e cattiva scelta di design. Eppure il caso è illuminante perché mostra quanto sia preciso e implacabile il controllo editoriale esercitato su ciò che entra nel kernel.

Perché un “no” rumoroso è sicurezza pratica

A prima vista, la reazione può sembrare sopra le righe. Ma chi apprezza Torvalds — e sono in molti — lo fa proprio per la combinazione di capacità tecnica e comunicazione senza fronzoli. Il punto non è lo stile più o meno brusco: è il messaggio tecnico. Un helper “comodo” messo in un header generico è una porta che spalanchi verso applicazioni improprie, ambiguità semantiche e abitudini sbagliate. Un conto è scrivere localmente una riga chiara ed esplicita, un altro è creare un’astrazione opaca che, per via della sua visibilità, potrebbe finire ovunque.

Non c’è alcun bisogno di evocare backdoor per giustificare una stroncatura. La sicurezza del software è fatta di gradazioni: ogni strato di opacità in più, ogni refactoring “ornamentale”, ogni utility “generica” rende l’audit un po’ più difficile e sposta il baricentro dalla chiarezza alla convenienza. È esattamente qui che il “firewall umano” aggiunge valore: impone l’esplicito, scoraggia il magico, protegge i confini.

“Approfittare della distrazione”: il pattern che preoccupa

Molti hanno sottolineato un aspetto: non c’è stata una backdoor; qualcuno ha provato a far passare un cambiamento superfluo approfittando del momento (fine merge window, pull corposa, refactoring di contorno). Può darsi fosse in buona fede; spesso lo è. Ma il pattern resta: raccogliere in una sola proposta tante cose diverse, infilando in mezzo una nuova astrazione “generica”.

È un modello ben noto anche in scenari meno innocui: gli attacchi alla supply-chain raramente si presentano come righe di codice palesemente maliziose; preferiscono nascondersi in refactoring, macro, helper, file condivisi. Per questo un “no” rumoroso a un helper ambiguo, oggi, vale a prevenire dieci problemi domani. Non perché ci sia un cattivo all’opera, ma perché riduce i nascondigli a disposizione di chiunque.

Come funziona davvero il controllo sul kernel

A scanso di equivoci: il kernel non è governato da un uomo solo al comando. L’architettura sociale è stratificata:

• Mantainer per sottosistema (filesystem, rete, architetture, driver) che raccolgono patch, le discutono su mailing list, le testano.

• Merge window a inizio ciclo per le feature; poi solo fix fino al rilascio.

• Pull request dai rami dei mantainer verso Linus, che fa da caporedattore.

• Regole culturali consolidate: preferenza per il codice esplicito, scope limitato, niente “omnibus patch”, niente utility generiche senza un razionale forte.

Torvalds è l’ultimo filtro e, soprattutto, il custode dei principi. Quando percepisce che un cambiamento sposta i confini (per esempio introducendo in un header comune qualcosa che non è davvero comune), tira il freno a mano. Può farlo con tatto variabile, ma la coerenza dei criteri è la vera garanzia.

Il parallelo con le pressioni esterne (il “caso Signal” come monito)

Quando si scherza su “backdoor governative”, non lo si fa dal nulla. Le pressioni politiche e regolatorie verso forme di “accesso eccezionale” ai sistemi cifrati esistono da anni; ogni tanto tornano sotto la forma di proposte come la scansione lato client. Non riguarda il kernel direttamente, ma il meccanismo è analogo: spostare il confine.

Se una norma ti impone di inserire nel client una scansione preventiva, ecco che qualcuno dovrà scrivere quel codice. È qui che l’open source mostra il suo valore: discussione pubblica, revisione feroce, rifiuto degli “helper” che diventano cavalli di Troia culturali. La lezione è valida anche per Linux: più i confini sono chiari, meno spazio resta per funzioni “di comodo” che aprono strade laterali.

L’effetto Torvalds: schiettezza come governance

Molti apprezzano Linus proprio perché “dice quello che pensa”. Può urtare la sensibilità di qualcuno, ma funziona perché allinea gli incentivi: se proponi un cambiamento, devi essere in grado di difenderlo tecnicamente. Non basta dire “si legge meglio”, “è più moderno”, “semplifica il codice”: serve dimostrare dove, quanto, a che prezzo, e soprattutto perché deve stare in un posto condiviso.

Questa schiettezza non è folclore: è governance. Fa risparmiare tempo, impedisce che la retorica del refactoring copra l’assenza di sostanza, e manda un messaggio chiaro ai contributori: giocate pulito, siate espliciti, niente scorciatoie.

La domanda scomoda: quanta centralizzazione è sostenibile?

Arriviamo al punto che inquieta molti: quanto è sostenibile un modello che, alla fine, conta sul “buon Linus”? È una domanda legittima. Il rischio non è solo il famigerato bus factor; è anche la scalabilità culturale: lo stile di chi sta in cima plasma i comportamenti.

La risposta migliore non è “de-linusizzare” il kernel, ma distribuire la cultura. In pratica:

• Far crescere reviewer forti nei sottosistemi, con potere reale di veto e responsabilità chiare.

• Documentare i principi con esempi concreti di patch rifiutate/accettate e motivazioni, così che il metodo resti anche se cambiano i nomi.

• Curare la successione: rotazioni, mentoring, allargamento della base di maintainer.

Così la centralizzazione diventa centralizzazione dei principi, non della persona. E possiamo sinceramente augurarci che il “buon Linus” non venga mai compromesso — ma senza fare di questo l’unico pilastro della sicurezza.

Dove stanno davvero i rischi oggi

Se vogliamo parlare seriamente di “backdoor”, dobbiamo guardare dove è più probabile che compaiano e non limitarci a pensare al kernel. I punti caldi sono altri.

• Librerie e tool di base meno presidiati ma onnipresenti — compressori, parser, installer — sono un bersaglio perfetto: vivono ovunque, spesso con meno occhi sopra, e un singolo bug o modifica malevola può avere effetto a catena su migliaia di sistemi.
• Catene di build e CI con permessi eccessivi, segreti condivisi e controlli di firma poco rigorosi sono un altro punto debole: se un attaccante compromette la pipeline, può inserire codice alterato direttamente negli artefatti, senza nemmeno toccare il sorgente pubblico.
• Poi ci sono le dipendenze transitive: pacchetti che entrano automaticamente, spesso senza versioni fissate e senza verifiche. È il terreno ideale per attacchi di typosquatting o takeover di account di maintainer.
• Infine, i refactoring massivi che toccano decine di file senza un beneficio misurabile. Generano rumore, rendono la revisione più difficile e creano l’occasione perfetta per nascondere modifiche indesiderate.

Il kernel, con tutti i suoi difetti, è più difficile da ingannare proprio perché il processo di revisione è duro e implacabile. Chi mette in produzione software per migliaia di utenti dovrebbe prendere esempio: adottare quella stessa severità a livello di policy, non affidarsi alla buona volontà di una singola persona.

Meno mito, più metodo. E il “firewall umano” resta acceso.

Tiriamo le somme. Nessuno ha inserito backdoor nel kernel in questa storia: il rifiuto è scattato per ragioni tecniche e di processo — tempistica sbagliata, ambiguità, collocazione in header condivisi. È proprio così che deve funzionare un progetto che alimenta il mondo: alzare l’asticella anche sulle “piccole cose”, perché sono quelle a fare da terreno fertile a compromessi peggiori.

Allo stesso tempo, è sano chiedersi quanto sia sostenibile contare su una singola figura carismatica. La risposta non è smettere di apprezzarla, ma trasformare il suo stile in regole trasmissibili: chiarezza, confini, responsabilità. Se istituiamo questi principi, il firewall umano diventa un attributo della comunità, non di una persona.

Fino ad allora, Linus Torvalds è un firewall umano. Non perché sia infallibile o immortale, ma perché incarna un modo di difendere il codice: niente scorciatoie, niente magie, niente “aiutini” infilati nei posti sbagliati. E se per un dettaglio così alza la voce, possiamo dormire un po’ più tranquilli: nel giorno in cui qualcuno proverà davvero a forzare la mano, quel firewall saprà fare rumore — e, soprattutto, saprà dire di no.