Non è un attacco esterno, non c’entrano vulnerabilità zero-day né supply chain compromesse nel senso classico. La notte in cui i repository di OpenMandriva sono stati sventrati, la minaccia aveva un volto noto, l’accesso da amministratore fidato e, a quanto pare, una ruggine personale che ribolliva da tempo. Il progetto accusa Davide Beatrici, sviluppatore conosciuto per il client VoIP Mumble, di aver cancellato rami GitHub su cui giacevano anni di lavoro e di aver pubblicato un pacchetto vuoto capace di disinstallare in blocco i desktop environment GNOME e COSMIC su chi usava il ramo rolling Cooker. Danni circoscritti alla bleeding edge, per fortuna, ma sufficienti a innescare un ripristino d’emergenza e una riflessione amara: cosa succede quando chi custodisce le chiavi dell’infrastruttura decide di usarle per fare del male?

La cronistoria ricostruita dal forum ufficiale è quella di una disputa comunitaria degenerata. Beatrici aveva proposto e realizzato la migrazione dei repository su una propria istanza OneDev privata, accentrando di fatto il mirroring di decine di repo in un’unica infrastruttura personale. Alcuni maintainer erano a disagio, ma l’autorevolezza del contributore fece passare la scelta. Poi l’arrivo di due nuovi collaboratori, uno dei quali avrebbe ripetutamente insultato utenti e membri del progetto in messaggi privati. La decisione di allontanarlo dalla chat Matrix di Cooker – senza bandirlo dal progetto – ha scatenato un effetto domino: dimissioni di Beatrici e di un altro sviluppatore, e infine la rimozione dei mirror verso l’infrastruttura privata. A quel punto, secondo OpenMandriva, l’ex contributor avrebbe usato i privilegi residui per sabotare la distribuzione.

Beatrici ha ribattuto, come riportato da The Lunduke Journal, che non si è trattato di sabotaggio ma di una reazione al fatto che qualcuno stava “mettendo mano al mio lavoro”. Ha ammesso di aver rimosso i repository GNOME e COSMIC, ma nega l’intento di danneggiare la distribuzione a cui teneva. Resta il gesto tecnico: cancellazione di risorse condivise e immissione di un meta-pacchetto pensato per obsoletare componenti critiche. Un’azione che, indipendentemente dai motivi, dimostra quanto sia sottile il confine tra privilegio operativo e danno sistemico.

Per chi oggi progetta o amministra stack on-premise dedicati all’inference di Large Language Models, l’episodio è un case study involontario sulla fragilità dei modelli di fiducia accentrati. In ambienti dove la sovranità dei dati impone che tutto – dai pesi dei modelli ai dataset di fine-tuning, dai log delle richieste ai container di serving – resti sotto controllo interno, il rischio insider non è un corollario teorico. È un parametro di progetto concreto, che chiama in causa controlli di accesso granulari, firma crittografica degli artefatti, backup immutabili e audit trail non ripudiabili. Non è solo questione di sicurezza perimetrale. Qui si tratta di impedire che una sola credential, magari lasciata attiva dopo un allontanamento burrascoso, possa rendere inutilizzabile una pipeline di inference o corrompere gli ambienti di staging.

La community Linux conosce liturgie di governance che nel tempo hanno prodotto strumenti come la separation of duties tra maintainer, le PolicyKit, i sistemi di build riproducibili. Eppure anche un progetto maturo come OpenMandriva si è trovato con un unico punto di rottura. L’analogia con le infrastrutture AI on-premise è diretta: molti team adottano soluzioni self-hosted – Kubernetes con operator per GPU, registry interni per le immagini container, storage condiviso per i checkpoint dei modelli – e spesso la gestione amministrativa cade su poche persone, se non su una sola. Se quella persona smette di essere allineata, il danno non si misura in ore di downtime: può voler dire ricostruire ambienti da zero, perdere commit non altrove replicati, compromettere la fiducia verso clienti interni o esterni.

La lezione strutturale non è “non fidarti dei tuoi amministratori”, ma che la fiducia va ingegnerizzata esattamente come si ingegnerizza un cluster di GPU: con ridondanza, rotazione delle credenziali, approval workflow per le modifiche distruttive e, soprattutto, con una separazione che impedisca a chiunque di essere contemporaneamente committer, approver e detentore esclusivo delle chiavi. OpenMandriva sta facendo auditing e ripristinando i repo, e ha deciso di non procedere legalmente nonostante ritenesse il gesto un illecito penale. Ma per chi oggi guarda a deployment on-premise di AI come garanzia di controllo, l’incidente lascia un messaggio nitido: il controllo non vale nulla se non è distribuito. La sovranità vera inizia nel momento in cui ci si assicura che nessuna persona da sola possa cancellare il lavoro di tutti.

Beatrici sostiene di aver solo cancellato dei repository e di averlo fatto perché qualcuno gli stava mettendo mano. OpenMandriva parla di sabotaggio. Al di là della vertenza personale, ciò che resta è la dimostrazione empirica che le architetture di fiducia basate su singoli individui sono un lusso che nessun progetto – open source o enterprise che sia – può più permettersi.