Build reprodutível

Um build reprodutível produz um resultado idêntico bit a bit sempre que alguém constrói o mesmo código-fonte com o mesmo ambiente de build e as mesmas instruções de build. É a definição do projeto Reproducible Builds. O resultado são aqui os artefactos que o build deve produzir: executáveis, pacotes de distribuição, imagens de contentor ou de sistema de ficheiros. Os registos não contam. «Volta a compilar» não é a mesma coisa; reprodutível significa que os bytes coincidem.

Porque a maioria dos builds não é reprodutível

• Resolução de dependências durante o build. Sem lockfile, um gestor de pacotes escolhe as versões enquanto o build decorre. A resolução no PyPI pode terminar de forma diferente consoante a ordem em que chegam as respostas, um intervalo de versões desloca-se quando sai uma nova versão e uma etiqueta mutável como latest passa a apontar para outro lado.
• O ambiente. Carimbos temporais, caminhos de ficheiros, as definições regionais e as ferramentas do próprio anfitrião acabam dentro dos artefactos.
• O acaso. Os passos de build podem gerar identificadores, ordenar ficheiros por hash ou executar tarefas em paralelo por uma ordem diferente de cada vez.

Construir o mesmo commit duas vezes seguidas não garante, portanto, o mesmo resultado nem a mesma SBOM. Um build que transfere código que o seu lockfile não lista, uma dependência oculta, torna tudo pior.

Como as equipas tornam os builds reprodutíveis

• Fixe e bloqueie cada entrada, incluindo as imagens base por digest e as ferramentas por versão (veja lockfile).
• Use uma hora fixa em vez do relógio: SOURCE_DATE_EPOCH é uma variável de ambiente normalizada com um carimbo temporal Unix que as ferramentas de build usam em vez da hora atual.
• Remova ou normalize os caminhos de build, ordene as listas de ficheiros e fixe as definições regionais.
• Construa num ambiente hermético cuja cadeia de ferramentas também esteja fixada. O Nix é uma forma de o fazer.
• Verifique-o: construa o mesmo commit duas vezes, de forma independente (noutra máquina, noutro caminho, noutro dia), e compare os resultados. Onde os hashes diferirem, o diffoscope mostra exatamente o que mudou.

O Yocto Project mostra porque a reprodutibilidade é uma propriedade a verificar e não a presumir. A sua documentação diz que os builds do projeto são reprodutíveis «até ao nível binário, incluindo carimbos temporais» desde a versão 3.1, que só o BitBake e o OpenEmbedded-Core garantem reprodutibilidade completa e que «no momento em que acrescenta outra camada, esta garantia deixa de valer». O projeto testa-o com oe-selftest.

Builds reprodutíveis e SBOM

Se todos os builds fossem reprodutíveis, poderia reconstruir mais tarde uma versão antiga e gerar a sua SBOM. A maioria não é, por isso uma reconstrução, ou uma análise do código-fonte hoje, descreve um build parecido, não o que distribuiu. A SBOM que mostra o que está em produção é a registada no build de CI que produziu a versão.

Nem um build reprodutível dispensa esse registo. Hashes coincidentes provam que dois builds produziram o mesmo resultado; não listam o que lá entrou. Continua a precisar do inventário e de uma indicação honesta da sua completude da SBOM. Porque a CI é o lugar da segurança da cadeia de abastecimento e boas práticas de SBOM desenvolvem o argumento.

O SLSA trata a reprodutibilidade como uma forma de verificar que um build fez o que afirma.

A reprodutibilidade consegue-se no sistema de build, com ferramentas como Nix, Yocto ou as ferramentas da Debian. O CRACI não torna os builds reprodutíveis: regista a SBOM de cada build enquanto este decorre, para que o registo do que foi distribuído não dependa de uma reconstrução. Veja SBOM do momento do build.