TrueNAS chiude il build system: perché la scelta agita il mondo open

Il software di archiviazione TrueNAS occupa da anni una posizione centrale nel mondo dei NAS open source. La piattaforma sviluppata da iXsystems ha costruito la propria reputazione sulla combinazione tra il file system ZFS e un modello di sviluppo pubblico che ha permesso a ricercatori, amministratori di sistema e appassionati di studiare e migliorare il codice. Una modifica recente nella gestione del progetto ha però riacceso il dibattito sulla reale apertura del software. Il repository pubblico del sistema di build di TrueNAS non riceverà più aggiornamenti e lo sviluppo proseguirà su infrastrutture interne controllate dall’azienda.

La decisione emerge da un aggiornamento del repository ufficiale utilizzato per costruire le immagini ISO di TrueNAS SCALE. La documentazione indica chiaramente che il codice resterà disponibile come riferimento storico ma non saranno accettate nuove modifiche, segnalazioni o pull request.

Il processo di compilazione che produce le versioni ufficiali del sistema operativo sarà d’ora in avanti gestito esclusivamente all’interno dell’infrastruttura privata del produttore. L’annuncio non riguarda direttamente il codice sorgente del sistema operativo, che rimane distribuito con licenze open source, ma interviene su un elemento fondamentale della filiera di sviluppo: il meccanismo che trasforma il codice in un sistema installabile.

TrueNAS: il ruolo del build system nel ciclo di sviluppo

Un progetto come TrueNAS non ha bisogno di presentazioni: include centinaia di componenti software, tra cui il kernel Linux, il file system ZFS, servizi di rete, strumenti di virtualizzazione e l’interfaccia di gestione Web. Coordinare la compilazione di tutti questi elementi richiede un’infrastruttura complessa, definita tecnicamente build system.

Nel caso di TrueNAS SCALE, piattaforma Linux per creare sistemi di storage di rete avanzati, pensata per ambienti domestici evoluti, laboratori IT e infrastrutture enterprise, tale infrastruttura deriva dal mondo Debian e utilizza script di automazione per assemblare il sistema finale, produrre le immagini ISO e verificare l’integrità dei pacchetti.

Il repository pubblico denominato scale-build conteneva proprio queste istruzioni: script di compilazione, definizioni delle dipendenze, configurazioni del kernel e strumenti per generare le immagini di installazione. Chiunque poteva clonare il progetto, replicare la build e produrre una propria versione del sistema operativo. In teoria questo approccio garantiva la massima trasparenza: il codice pubblicato coincideva con quello usato per generare le distribuzioni ufficiali.

Quando un build system diventa “interno”, la situazione cambia. Il codice del sistema operativo può restare accessibile, ma il processo che genera la distribuzione ufficiale non è più completamente riproducibile da terze parti. In ambito open source questa caratteristica è nota come reproducible builds, una proprietà che consente di verificare che il software distribuito corrisponda esattamente al codice pubblicato.

Le ragioni tecniche dietro la scelta

Secondo i responsabili del progetto, il cambiamento deriva principalmente da nuove esigenze di sicurezza legate alla distribuzione del sistema operativo. Tra i fattori citati compare il supporto a Secure Boot, il meccanismo introdotto nei firmware UEFI che impedisce l’avvio di software non firmato. Per rendere compatibile TrueNAS con questo modello di sicurezza è necessario gestire con maggiore controllo la fase di firma crittografica delle immagini e dei componenti di boot.

La firma del software richiede l’uso di chiavi private custodite in ambienti protetti. In molte organizzazioni queste chiavi sono conservate all’interno di Hardware Security Module o infrastrutture isolate dalla rete pubblica. Integrare tali sistemi in un processo di build completamente pubblico risulta complesso, perché l’intero flusso deve garantire che le chiavi non possano essere esposte o manipolate.

Il team di sviluppo ha spiegato che mantenere due infrastrutture parallele – una pubblica per la comunità e una interna per le build ufficiali – avrebbe comportato costi operativi elevati. Un build system aperto avrebbe dovuto replicare lo stesso ambiente di compilazione utilizzato dall’azienda, inclusi strumenti di firma e controlli di integrità. L’azienda ha quindi deciso di concentrare lo sviluppo su una singola piattaforma interna.

Cosa resta realmente open source

La distinzione tra codice e processo di build genera spesso confusione. Il software TrueNAS continua a essere distribuito sotto licenze open source, in larga parte GPLv3.

Significa che il codice sorgente dei componenti principali resta accessibile e può essere modificato o redistribuito da terze parti. La stessa architettura del sistema operativo dipende da progetti open source come il kernel Linux e ZFS.

La chiusura del build system non impedisce quindi la creazione di fork o distribuzioni derivate. Tuttavia rende più difficile replicare fedelmente la versione ufficiale del sistema operativo.

Il contesto evolutivo del progetto TrueNAS

Il progetto TrueNAS ha attraversato diverse trasformazioni negli ultimi anni. La piattaforma deriva da FreeNAS, una distribuzione nata nei primi anni 2000 con l’obiettivo di semplificare l’uso del file system ZFS su hardware standard. Nel 2020 iXsystems ha introdotto la variante Linux chiamata TrueNAS SCALE, progettata per supportare container e infrastrutture distribuite.

Nel tempo la versione basata su Linux ha progressivamente sostituito quella storica basata su FreeBSD. L’azienda ha poi unificato la linea di sviluppo in un’unica piattaforma che offre una Community Edition gratuita e una edizione Enterprise destinata ai sistemi di storage professionali.

Si tratta di un’evoluzione che ha trasformato TrueNAS da semplice distribuzione NAS domestica a piattaforma di storage utilizzata anche in ambienti aziendali.

Funzioni come replica ZFS, snapshot, supporto SMB e NFS avanzato, oltre alla gestione di container e macchine virtuali, collocano il software in un segmento molto più vicino alle infrastrutture enterprise rispetto alle origini del progetto.

Le implicazioni per la comunità e per gli utenti

La decisione di internalizzare il build system non modifica l’uso quotidiano di TrueNAS per chi installa il sistema tramite le immagini ufficiali.

L’utente domestico o l’amministratore di sistema che utilizza il NAS come piattaforma di archiviazione continuerà a ricevere aggiornamenti e nuove versioni senza differenze operative.

L’impatto si concentra soprattutto sulla trasparenza del processo di sviluppo. Nei progetti open source più rigorosi l’intero percorso che porta alla creazione dei binari pubblici resta documentato e replicabile. Quando parte di quel processo diventa privato, la comunità perde una parte della visibilità sulle modalità con cui il software è assemblato e distribuito.

La questione riguarda anche la fiducia nella filiera del software. Nell’ambito della sicurezza informatica cresce l’attenzione verso i rischi della cosiddetta supply chain, ovvero la possibilità che codice malevolo venga introdotto nel processo di compilazione.

L’adozione di build riproducibili rappresenta una delle strategie più efficaci per mitigare questo rischio. La scelta di gestire internamente l’infrastruttura di build rafforza il controllo dell’azienda sul processo, ma riduce la verificabilità indipendente.