Debian 14 ‘Forky’ será a primeira grande distribuição que exige compilações reproduzíveis

A lição principal: se você não consegue reproduzir um binário a partir de sua fonte, você não pode saber o que ele realmente faz. O código malicioso do backdoor XZ estava presente apenas nos tarballs de lançamento — não no repositório git. Uma configuração de compilação reproduzível teria sinalizado imediatamente essa discrepância: o tarball e o git checkout teriam produzido binários diferentes e a compilação teria sido rejeitada.

Este foi o upstream ao qual o anúncio do Debian está respondendo.

O mecanismo de fiscalização: o que realmente mudou

O projeto Reproducible Builds (reproducible-builds.org) existe desde 2014. O Debian tem sido um participante principal — a infraestrutura de CI do projeto roda predominantemente em hardware Debian. Mais de 95% dos pacotes fonte do Debian já eram reproduzíveis antes deste anúncio. O que mudou em 10 de maio foi a adição de um hard gate nas ferramentas de migração.

Veja como funciona o fluxo de lançamento do Debian:

1. Os mantenedores do pacote fazem upload para unstable (Sid)
2. Após um atraso na migração (normalmente de 5 a 10 dias), os pacotes são considerados para promoção para testing
3. O software de migração aplica verificações automatizadas: resolução de dependências, suporte de arquitetura, status de rastreamento de bugs e reprodutibilidade

Antes de 10 de maio, a reprodutibilidade era verificada, mas era de caráter consultivo – uma nota em um painel. Agora é uma verificação de bloqueio. Se um pacote foo versão 2.0-1 não for reproduzível ou se a versão 2.0-1 tornar foo irreprodutível quando a versão 1.0-1 era reproduzível, a ferramenta de migração se recusará a promovê-lo.

Isso é reforçado verificando os arquivos .buildinfo — artefatos que registram o ambiente de compilação completo: cada versão de dependência, cada flag do compilador, o caminho de compilação, a versão do kernel, as configurações de localidade. Combinado com diffoscope (uma ferramenta que compara profundamente dois binários e relata cada diferença no nível de byte), o sistema pode determinar se o código-fonte de um pacote produz saída idêntica em compilações independentes.

A consequência prática: os mantenedores do Debian agora devem corrigir problemas de reprodutibilidade antes que seus pacotes possam chegar aos usuários através do pipeline de lançamento estável. Eles não podem contornar isso com patches ou fechamento de bugs – o portão de migração os impede.

O significado mais profundo: o que isso realmente significa### 1. A mudança do modelo de confiança: de “Confie em nós” para “Verifique-nos”

Todo sistema de distribuição de pacotes binários opera em um modelo confiável. Antes desta mudança, o modelo de confiança era: “Os daemons de compilação do Debian são seguros; confie que o binário que enviamos corresponde à fonte que mostramos a você.”

Após essa alteração, o modelo muda para: “Qualquer pessoa pode verificar, de forma independente, se o que enviamos corresponde à origem. Caso contrário, o sistema se recusa a enviá-lo.”

Esta é uma distinção significativa. Isso significa que um comprometimento da infraestrutura de compilação do Debian — digamos, um invasor que obtenha acesso ao cluster do daemon de compilação e modifique os binários pós-compilação — seria detectável por qualquer um executando uma reconstrução. O invasor também precisaria comprometer todas as verificações de reconstrução independentes, o que é um alvo substancialmente mais difícil.

2. A pressão econômica no upstream

Uma consequência subestimada: projetos upstream que não suportam compilações reproduzíveis serão congelados fora do Debian. Se o sistema de compilação de um projeto upstream incorpora carimbos de data e hora, depende da ordem readdir do sistema de arquivos ou gera identificadores aleatórios durante a compilação, o mantenedor do pacote Debian está agora no gancho para corrigir esses problemas ou argumentar por uma exceção.

Os “Mandments of Reproducible Builds” documentam as fontes mais comuns de não-determinismo:

• Carimbos de data e hora: data de construção incorporada em binários (corrigida via SOURCE_DATE_EPOCH)
• Ordenação do sistema de arquivos: readdir() retornando arquivos em ordem arbitrária (corrigido por meio de classificação determinística ou arquivos ar)
• Caminho de construção: /home/user/build/foo vs /build/foo produzindo saída diferente (corrigido via -ffile-prefix-map ou BUILD_PATH_PREFIX_MAP)
• Locales: sort produzindo ordem diferente em en_US.UTF-8 vs zh_CN.UTF-8 (corrigido pela configuração de LANG=C)
• Aleatoriedade: nomes de arquivos temporários gerando UUIDs (devem ser determinísticos)
• Fusos horários: saída variando de acordo com o fuso horário (deve ser fixado em UTC)

Cada um deles pode ser resolvido, mas cada um requer trabalho. A consequência é que o Debian está agora exercendo pressão econômica downstream sobre todo o ecossistema de código aberto para adotar práticas determinísticas de construção. Este pode ser o impacto mais significativo do anúncio no nível do ecossistema.

3. Efeitos downstream: Ubuntu, Kali e além

Debian é o upstream de mais de 120 distribuições derivadas, incluindo Ubuntu, Kali Linux, Linux Mint, MX Linux, Raspberry Pi OS e Tails. Quando o Debian exige compilações reproduzíveis para sua ramificação testing, todo derivado que rastreia testing herda esta garantia.

O Ubuntu em particular é digno de nota. Durante o incidente XZ, a Canonical atrasou o Ubuntu 24.04 LTS beta e realizou uma reconstrução completa do arquivo — uma operação extremamente cara. Um pipeline de construção reproduzível teria reduzido drasticamente o custo de verificação: em vez de reconstruir mais de 30.000 pacotes, a Canonical poderia ter reconstruído seletivamente apenas os pacotes onde o artefato de construção não correspondesse ao hash esperado.

4. Comparação com outras distribuições

O análogo existente mais próximo é o NixOS, que tem construções reproduzíveis como objetivo principal do design desde o início. O armazenamento endereçado a conteúdo do Nix oferece suporte inerente à verificação de reprodutibilidade. No entanto, o NixOS nunca exigiu reprodutibilidade universal - o ecossistema Nix tem uma porcentagem semelhante de pacotes que são construídos de forma determinística (alta década de 90), mas sem o hard gate que o Debian acabou de introduzir.

Guix é ainda mais avançado — ele vai um passo além com compilações bootstrappable, com o objetivo de reduzir a base de computação confiável a uma pequena semente binária que pode ser auditada manualmente.

Fedora tem trabalhado em compilações reproduzíveis, mas não anunciou uma política rígida. Arch Linux atualmente não possui infraestrutura de build reproduzível em sua cadeia de ferramentas de empacotamento.

A mudança do Debian é notável porque é a primeira distribuição mainstream e de uso geral a tornar a reprodutibilidade um requisito difícil — não um recurso, não uma melhor prática, mas uma porta.

5. LoongArch64: Uma dimensão geopolíticaO anúncio simultâneo de LoongArch64 (Loong64) entrando no arquivo Debian vale a pena notar no contexto. LoongArch é um CPU ISA chinês desenvolvido pela Loongson Technology, projetado como uma alternativa ao x86 e ARM. Loongson tem pressionado por um suporte mais amplo ao ecossistema de software, e a versão LoongArch do Debian é um marco significativo.

O momento é interessante. Ao exigir compilações reproduzíveis ao mesmo tempo que adiciona uma nova arquitetura de um país com diferentes interesses de segurança cibernética, o Debian cria uma forte estrutura de confiança: qualquer pessoa pode verificar se os binários LoongArch correspondem às suas fontes, reduzindo a necessidade de confiar na infraestrutura de construção num contexto geopoliticamente sensível.

O que está faltando: os problemas difíceis permanecem

Apesar de toda a sua ambição, esta política não resolve todos os problemas da cadeia de abastecimento:

O problema do bootstrap. O primeiro compilador usado para construir o Debian deve ser confiável. Compilações reproduzíveis podem verificar se o compilador é autoconsistente, mas não podem provar a ausência de um [ataque de confiança confiável no estilo Ken Thompson] (https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Reflections_on_Trusting_Trust.pdf) - onde um compilador comprometido insere backdoors em cada programa que compila, incluindo versões futuras de si mesmo. O esforço de construção bootstrappable do Guix resolve isso, mas o Debian ainda não o adotou.

Reprodutibilidade ≠ segurança. Um binário reproduzível ainda pode ser vulnerável. A reprodutibilidade garante que o binário corresponda à fonte — não garante que a fonte esteja livre de erros. A vulnerabilidade OpenSSH CVE-2024-6387 (regreSSHion), que afetou milhões de servidores em 2024, não teria sido detectada por compilações reproduzíveis.

Compilações dependentes de hardware. Alguns pacotes produzem resultados diferentes dependendo dos recursos da arquitetura da CPU ou dos conjuntos de instruções disponíveis. A verdadeira reprodutibilidade em diferentes hardwares de construção continua a ser um desafio.

A conclusão

O Debian 14 “Forky” não será apenas mais um lançamento — ele marca o momento em que compilações reproduzíveis passaram de uma preocupação especializada para um requisito mainstream. O backdoor XZ demonstrou que o modelo de ameaça é real e que o modelo de confiança orientado por voluntários do ecossistema de código aberto é frágil. A resposta do Debian não é adicionar mais confiança — é tornar a confiança verificável através de código.

O portal de migração já está ativo. O esforço de uma década do projeto Reproducible Builds atingiu a sua fase de aplicação. Cada mantenedor de pacotes, cada projeto upstream e cada distribuição derivada sentirão as consequências.

A era do “confie em nós, nós construímos” está terminando. A era do “verifique-nos, veja como” começa com o Debian 14.