- O Fedora está promovendo uma mudança no Fedora 43 para tornar reproduzíveis 99% de todos os pacotes
- Com melhorias na infraestrutura existente, já atingiu 90%, e o plano para o restante é fazer com que os empacotadores reconheçam esses casos como bugs e os resolvam
- O objetivo é reforçar a segurança e melhorar a qualidade dos pacotes, além de introduzir também a ferramenta de verificação independente
rebuilderd
Visão geral da reprodutibilidade de builds em código aberto (Reproducible Builds)
- Para reforçar a segurança do software de código aberto e verificar sua integridade, os "builds reproduzíveis" estão se tornando cada vez mais importantes
- Um build reproduzível é um build em que qualquer pessoa pode gerar o mesmo resultado usando o mesmo código-fonte, ambiente de build e comandos de build
- O Debian está mais de 10 anos à frente nessa área, e atualmente até seus Live CDs oficiais podem ser produzidos de forma reproduzível
- O Fedora começou a trabalhar com builds reproduzíveis mais recentemente, mas está avaliando uma proposta para tornar reproduzíveis 99% de todos os pacotes no ciclo de desenvolvimento do Fedora 43
Diferenças entre Fedora e Debian
- O Debian permite o envio de pacotes compilados localmente, o que pode reduzir a confiabilidade
- O Fedora compila todos os pacotes centralmente em uma infraestrutura fortemente controlada
- O Fedora facilita o rastreamento de pacotes ao incluir código-fonte e informações de hash em um repositório Git chamado
dist-git
A definição de build reproduzível adotada pelo Fedora
- O Fedora usa uma definição diferente da do Debian
- Exclui assinaturas (
signature) e alguns metadados, focando no conteúdo real (payload) do arquivo RPM
- O motivo está nas características do formato RPM e no modo como as assinaturas funcionam, além da inclusão de informações como hora do build (
BUILDTIME) e host de build (BUILDHOST)
- O openSUSE resolve isso definindo
BUILDHOST como reproducible
Avanços técnicos do Fedora rumo a builds reproduzíveis
- Desde o Fedora 38, foi aplicada uma mudança que usa
SOURCE_DATE_EPOCH para fixar o horário de modificação dos arquivos
- No Fedora 41, foi introduzida a ferramenta baseada em Rust
add-determinism, que padroniza os metadados dos arquivos gerados no build
- O Debian usa a biblioteca Perl
strip-nondeterminism, mas o Fedora escolheu uma ferramenta própria para evitar dependências de Perl
- Até agora, já foi alcançada reprodutibilidade em cerca de 90% dos pacotes
Próximos planos
- O plano para os 9% restantes é incentivar os empacotadores a tratarem problemas de não reprodutibilidade como bugs e corrigi-los
- Será fornecido o utilitário
fedora-repro-build para testar localmente se um build do Koji é reproduzível
- Há planos de operar publicamente um sistema de verificação independente chamado
rebuilderd, que analisa metadados de pacotes e verifica a reprodutibilidade por meio de rebuilds
- O
rebuilderd pode gerar relatórios de diferenças com diffoscope
Diretrizes de empacotamento e melhoria de qualidade
- As diretrizes de empacotamento do Fedora devem ser atualizadas para "deve ser compilado de forma reproduzível quando possível"
- Builds reproduzíveis contribuem não só para a segurança, mas também para a melhoria da qualidade dos pacotes
- Exemplo: se for encontrada dependência de hardware em um pacote independente de arquitetura, isso provavelmente é um bug
Casos de exceção não reproduzíveis
- O Haskell não é reproduzível em builds multithread, e há trabalho em andamento para corrigir isso
- O Go não é reproduzível porque o arquivo de depuração
.gdb_index não é estável, e ainda não há solução
- Assinaturas de módulos do kernel Linux usam chaves temporárias, e um patch relacionado foi proposto
Feedback da comunidade
- A equipe de infraestrutura do Fedora levantou dúvidas sobre a localização e a manutenção do
rebuilderd
- Também foi discutido se seria possível integrar o
rebuilderd ao Koji
- Houve também a opinião de que usar um sistema fora do Koji é desejável para verificação independente
- Alguns sugeriram usar o Copr no lugar do
rebuilderd
- De forma geral, foi preferida uma direção que aumente a integração com as ferramentas já existentes do Fedora
Próximos passos
- Está previsto o envio de um ticket de proposta ao FESCo (Fedora Engineering Steering Committee)
- Se aprovado, o plano é acelerar a execução até outubro, meta de lançamento do Fedora 43
- Os usuários finais provavelmente não perceberão muita diferença, mas é uma mudança muito valiosa do ponto de vista da segurança da cadeia de suprimentos
7 comentários
A equipe do Fedora sempre me surpreende e dá a sensação de que a maioria das decisões está evoluindo na direção certa. Uso com gratidão, agradecendo a todos que contribuem sempre.
Acho que era muito usado antigamente, mas por que será que foi esquecido hoje em dia?
Ainda é muito popular na comunidade Linux para uso em desktop Linux.
Como não é uma distribuição voltada para servidores, parece que não tem tanta visibilidade no nosso país, onde o desktop Linux não é muito ativo.
Ah, hoje em dia, a menos que você seja um usuário avançado, parece que acaba escolhendo o Ubuntu, que pode ser usado tanto em servidor quanto em desktop!
Fico feliz de ver um assunto sobre Linux, então resolvi comentar também.. hehe
O Ubuntu, desde a adoção do snap, acabou perdendo muita boa vontade no segmento desktop.. e o Unity DE também divide bastante opiniões.. além disso, o ciclo de lançamento é longo demais, então o suporte aos drivers mais recentes também não funciona muito bem..
Se você está considerando usar Linux no desktop, recomendo Fedora de verdade.
O Fedora usa um Gnome mais próximo do puro, e o Gnome também vem recebendo ótimas atualizações recentemente, então estou realmente muito satisfeito!
Obrigado, haha
Quando falam de Fedora, isso me traz lembranças antigas.
Comentários do Hacker News