Build riproducibile

Una build riproducibile produce un output identico bit per bit ogni volta che qualcuno compila lo stesso codice sorgente con lo stesso ambiente di build e le stesse istruzioni di build. È la definizione del progetto Reproducible Builds. L'output indica qui gli artefatti che la build deve produrre: eseguibili, pacchetti di distribuzione, immagini di container o di file system. I log non contano. «Compila di nuovo» non è la stessa cosa; riproducibile significa che i byte coincidono.

Perché la maggior parte delle build non è riproducibile

• Risoluzione delle dipendenze durante la build. Senza lockfile, un gestore di pacchetti sceglie le versioni mentre la build è in corso. La risoluzione su PyPI può dare esiti diversi a seconda dell'ordine in cui arrivano le risposte, un intervallo di versioni si sposta quando esce una nuova release e un tag mutabile come latest punta altrove.
• L'ambiente. Timestamp, percorsi dei file, impostazioni locali e strumenti dell'host finiscono negli artefatti.
• La casualità. I passi di build possono generare ID, ordinare file per hash o eseguire lavori in parallelo in un ordine diverso ogni volta.

Compilare due volte di seguito lo stesso commit non garantisce quindi lo stesso risultato, né la stessa SBOM. Una build che scarica codice che il suo lockfile non elenca, una dipendenza nascosta, peggiora le cose.

Come i team rendono riproducibili le build

• Fissi e blocchi ogni input, comprese le immagini base per digest e gli strumenti per versione (veda lockfile).
• Usi un orario fisso al posto dell'orologio: SOURCE_DATE_EPOCH è una variabile d'ambiente standard con un timestamp Unix che gli strumenti di build usano al posto dell'ora corrente.
• Rimuova o normalizzi i percorsi di build, ordini gli elenchi di file e fissi le impostazioni locali.
• Compili in un ambiente ermetico la cui toolchain sia a sua volta fissata. Nix è un modo per farlo.
• Lo verifichi: compili lo stesso commit due volte, in modo indipendente (su un'altra macchina, in un altro percorso, in un altro giorno), e confronti gli output. Dove gli hash differiscono, diffoscope mostra esattamente che cosa è cambiato.

Lo Yocto Project mostra perché la riproducibilità è una proprietà da verificare, non da presumere. La sua documentazione afferma che le build del progetto sono riproducibili «fino al livello binario, timestamp compresi» dalla release 3.1, che solo BitBake e OpenEmbedded-Core garantiscono una riproducibilità completa e che «nel momento in cui aggiunge un altro layer, questa garanzia decade». Il progetto lo verifica con oe-selftest.

Build riproducibili e SBOM

Se ogni build fosse riproducibile, potrebbe ricompilare in seguito una vecchia release e generarne la SBOM. La maggior parte non lo è, quindi una nuova compilazione, o una scansione del codice sorgente oggi, descrive una build simile, non quella che ha distribuito. La SBOM che mostra che cosa è in produzione è quella registrata dalla build CI che ha prodotto la release.

Nemmeno una build riproducibile rende superflua quella registrazione. Hash coincidenti dimostrano che due build hanno prodotto lo stesso output; non elencano che cosa vi è entrato. Le serve comunque l'inventario, e una dichiarazione onesta della sua completezza della SBOM. Perché la CI è il luogo della sicurezza della supply chain e le best practice SBOM sviluppano l'argomento.

SLSA considera la riproducibilità uno dei modi per verificare che una build abbia fatto ciò che dichiara.

La riproducibilità si ottiene nel sistema di build, con strumenti come Nix, Yocto o quelli di Debian. CRACI non rende riproducibili le build: registra la SBOM di ogni build durante l'esecuzione, così che la traccia di ciò che è stato distribuito non dipenda da una nuova compilazione. Veda SBOM in fase di build.