Reproducible Firmware Build

A afirmação refere-se a uma saída definida, como uma imagem de firmware, não automaticamente a todos os ficheiros ou registos. Comportamento equivalente do programa não basta: procuram-se bytes idênticos, normalmente através de um hash criptográfico. Código aberto sem compilação repetível não demonstra por si só essa ligação ao binário publicado. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]

Registe o commit exato, dependências e respetivas versões, compilador, opções de compilação, variáveis de ambiente relevantes e modelo de destino. O nome do projeto ou uma branch que muda não bastam. A informação necessária para repetir deve ser publicada ou registada durante a compilação; caso contrário, as diferenças não podem ser avaliadas com fiabilidade. [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]

Um compilador pode gravar o caminho do diretório de trabalho na informação de depuração. O mesmo código em dois locais pode assim gerar ficheiros diferentes. O caminho pode ser definido antecipadamente ou normalizado por um procedimento suportado. Essa regra deve integrar a receita; apagar depois diferenças desconhecidas comprometeria a verificação. [Reproducible Builds — Build paths]

Uma assinatura válida liga uma publicação à respetiva chave de assinatura num dado modelo de confiança. Uma compilação independente examina a relação entre o código e o resultado binário. O ficheiro oficial assinado pode conter dados ausentes numa compilação local não assinada. Comparar simplesmente os ficheiros completos pode, por isso, não ser o teste correto da reprodutibilidade declarada. [Trezor — Reproducible build verification]

A documentação Trezor seleciona versão e modelo, cria a imagem no ambiente definido e compara-a com a publicação oficial. Antes da comparação, descreve o preenchimento com zeros de campos de assinatura exatos; os formatos antigos também diferem nos cabeçalhos. A estrutura depende do modelo e da versão. Não se deve aplicar cegamente o procedimento de uma imagem a outra; a assinatura original é verificada separadamente. [Trezor — Reproducible build verification]

Verifique primeiro a revisão, o modelo, a variante de firmware, as dependências e as transformações declaradas da imagem. Preserve os ficheiros originais e o registo da diferença. A divergência pode decorrer de um erro na receita ou no ambiente, mas também de uma alteração do binário distribuído; isoladamente não determina a causa. Não classifique o resultado como verificado antes de explicar a diferença e repetir a verificação. [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]

Código defeituoso ou malicioso pode ser perfeitamente reproduzível. Um compilador comum não fiável pode inserir a mesma alteração em todos os resultados; repetir a mesma ferramenta não é uma auditoria independente do compilador. Componentes binários fechados limitam o que pode ser reconstruído a partir do código disponível. Ficheiros iguais também não verificam a autenticidade do hardware nem o que está efetivamente instalado num dispositivo específico. [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]

Um registo útil indica quem compilou, a partir de que commit, com que receita, para que modelo e que ficheiros comparou. Inclua o algoritmo de hash, resultados e exceções exatas relativas às assinaturas. Mais pessoas a compilar independentemente reduzem a dependência de um único distribuidor, mas não substituem a análise do código, do processo de atualização e da segurança global do dispositivo. [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]