Quando pochi giorni fa abbiamo parlato delle 423 CVE pubblicate per il Kernel Linux, avevamo riportato le parole del maintainer Greg Kroah-Hartman il quale, alle persone perplesse per i numeri così alti, aveva languidamente risposto che “così è la vita” e, soprattutto, così sarà da qui in avanti.

Non solo, tra i vari approcci suggeriti per interpretare questo momento ed essere “sul pezzo” Kroah-Hartman aveva fatto un riferimento esplicito a Debian, dicendo:

If you can't pay a company, then just use Debian or Yocto as
their security practices are amazing and because of this, it turns out that those systems run the world (after Android.)

Se non puoi pagare un’azienda [per una subscriptio, ndr], allora usa Debian o Yocto visto che le loro pratiche di sicurezza sono fantastiche e proprio per questo il mondo funziona su questi sistemi (dopo Android).

Non sono un caso queste parole, e la dimostrazione pratica infatti è arrivata pochissimo tempo fa, precisamente il 31 luglio, quando all’interno della mailing list Security Announce del progetto un messaggio ha indicato la pubblicazione della nuova versione del Kernel Linux, la 6.12.100-1, che risolve ben 68 CVE facenti parte del pacchetto regalo di Kroah-Hartman.

Non solo, pochi giorni prima un altro pacchetto Kernel che risolveva 12 CVE era stato a sua volta pubblicato, il che porta il conto totale a 80 CVE risolte.

Oltre a dimostrare la validità di quanto indicato dal maintainer di Linux, vale la pena sottolineare anche il fatto che Debian è una distribuzione community, quindi senza alcun backup commerciale alle spalle e che, nonostante questo, risulta aggiornata al pari delle sorelle di classe enterprise.

Certo, la pubblicazione dei pacchetti è una cosa, ma senza l’aggiornamento effettivo degli stessi sui sistemi utilizzati tutto questo lavoro è chiaramente inutile.

Quante aziende hanno politiche di aggiornamento dei sistemi operativi serrate? Quante aziende non si sono ancora rese conto che se prima l’approccio poteva essere semestrale o trimestrale oggi questo deve essere settimanale? Esistono ancora aziende che hanno sistemi Single Point Of Failure (SPOF) che non possono essere spenti? Ah, a saperlo. O forse lo si sa, ma è meglio non dirlo.

Nel frattempo, visto che questa pioggia di CVE è stata chiaramente provocata dall’impiego di strutture AI per l’analisi e l’identificazione delle vulnerabilità nel codice, parlando di Debian, ecco profilarsi all’orizzonte l’abbozzo di una politica sui contributi generati mediante AI.

Il progetto Debian, per mano di Matthias Geiger, ha indetto una General Resolution, dal titolo: “Ban LLM contributions from Debian“, la cui proposta è riassunta così:

In the interest of not eroding Debian's reputation or further damaging the community, LLM-assisted contributions should be prohibited from inclusion in Debian. Though our position is that LLM contributions are contrary to documents already ratified by Debian, in order to remove all doubt, we propose the following addition to the Social Contract:

6. Works Created through the use of Large Language Models (LLMs)
   We will not allow direct contributions to Debian written with the use or assistance
   of large language models (LLMs) or other generative AI tools. Direct contributions are
   defined as packaging, native Debian software like lintian, documentation and translations
   written by Debian contributors, and official Debian web resources, etc. Other categories
   such as upstream projects written with LLM assistance may be included at a later date.
   This ensures that Debian remains a stable, trusted, and reliable operating system, and 
   protects the interests of the Debian volunteers who make it possible.

Quindi il passaggio chiave è quello dei contributi diretti: la pacchettizzazione, il software nativo di Debian come lintian (che automatizza il controllo di centinaia di linee guida stabilite dal Debian Policy Manual, il documento che definisce come deve essere realizzato un pacchetto Debian per essere considerato “conforme”), la documentazione e le traduzioni scritte dai collaboratori di Debian oltre alle risorse web ufficiali di Debian.

Tutte queste cose, escludendo progetti upstream scritti con l’assistenza di LLM i quali potranno essere inclusi in una data successiva, dovranno essere generate da un’entità umana e non mediante LLM, per garantire che Debian rimanga un sistema operativo stabile, affidabile e sicuro, proteggendo gli interessi dei volontari di Debian che lo rendono possibile.

Per chi non è familiare, le “General Resolution” (GR) sono uno strumento di voto utilizzato dalla comunità di Debian per prendere decisioni importanti su questioni fondamentali relative al progetto e rappresentano una delle principali forme di democrazia all’interno della comunità Debian, abbiamo discusso di molte GR in passato, ad esempio quella a proposito del sistema di init.

Dal thread di partenza menzionato sopra vengono emesse varie versioni o variazioni della GR, raggruppate qui https://www.debian.org/vote/2026/vote_002, ed al termine del periodo di discussione, che sarà il prossimo 8 agosto 2026, potrà essere avviata la fase di voto, nella quale tutti gli sviluppatori, ossia gli aventi diritto, potranno pronunciarsi (e un’opzione implicita è che nessuna delle proposte sia adeguata).

Vedremo quindi come ed in che forma il progetto si porrà a proposito dell’AI: l’unica cosa certa è che sarà una decisione democratica.