Debian deve fornecer pacotes reproduzíveis

 (lists.debian.org)
1 pontos por GN⁺ 5 시간 전 | 2 comentários | Compartilhar no WhatsApp
  • A equipe de lançamento do Debian decidiu, no meio do ciclo do forky, exigir o fornecimento de pacotes reproduzíveis
  • O software de migração bloqueia novos pacotes que não sejam reproduzíveis em reproduce.debian.net
  • A migração também é bloqueada quando surgem regressões de reprodutibilidade em pacotes já existentes no testing
  • O autopkgtest também foi adicionado ao binNMU, assim como nos uploads source-full
  • Com a adição do loong64 e os rebuilds multi-arch, a fila de CI cresceu e será preciso paciência

Obrigatoriedade de reprodutibilidade dos pacotes no Debian

  • A equipe de lançamento do Debian decidiu, no ponto intermediário do ciclo de lançamento do forky, que o Debian deve fornecer pacotes reproduzíveis
  • Essa decisão foi impulsionada pelos esforços do projeto Reproducible Builds
  • Desde ontem, foi ativado o bloqueio, pelo software de migração, da migração de novos pacotes que não sejam reproduzíveis em reproduce.debian.net
  • A migração também é bloqueada quando ocorre uma regressão de reprodutibilidade em pacotes já presentes no testing

Garantia de qualidade e responsabilidade dos uploaders

  • Execução de autopkgtest para binNMU no testing

    • No início deste ano, foi adicionada ao software de migração a capacidade de executar autopkgtest também para binNMU, assim como já acontece com uploads source-full
    • Esse recurso pode não ter relação direta com a maior parte do trabalho dos maintainers, mas é tratado como mais um passo para reforçar a garantia de qualidade

  • Adição da arquitetura loong64 e aumento da fila de CI

    • Há duas semanas, a nova arquitetura loong64 foi adicionada ao arquivo
    • O Debian permite a migração apenas de binários compilados no buildd e, por causa dos requisitos de multi-arch, foi necessário reconstruir uma quantidade significativa de pacotes em todas as arquiteturas
    • Por causa do recurso de binNMU adicionado anteriormente, a fila de CI atualmente está bastante grande, e a equipe de lançamento pede um pouco de paciência

  • Acompanhamento após o upload

    • O uploader do pacote-fonte é responsável por garantir que o pacote consiga migrar
    • Se o pacote estiver bloqueado por uma regressão de autopkgtest em uma dependência de teste reversa e for necessária uma atualização dessa dependência, o uploader deve registrar um bug com severidade RC apropriada

Leituras relacionadas

2 comentários

 
GN⁺ 2 시간 전
Comentários do Hacker News

  • É uma grande conquista para o Debian e para o mundo do software livre.
    Só que demorou bastante para entenderem por que isso era necessário. Quando eu disse no debian-devel, em 2007, que isso era necessário, responderam que era uma enorme perda de tempo. E realmente foi preciso um trabalho imenso de muita gente para chegar até aqui, mas valeu muito a pena

    • Desde 2007, não houve nenhum bug ou ataque no Debian que os pacotes reproduzíveis teriam conseguido impedir.
      Então não acho correto dizer que “valeu a pena”. Isso só aumenta a barreira de contribuição no Debian, e eu já vi muita gente reclamar que contribuir com o Debian já é difícil. Antes eu defendia com o argumento de que “é preciso todo tipo de verificação e controle para que os pacotes se encaixem bem entre si”, mas isto parece apenas mais uma etapa que dificulta sem grande motivo e traz pouco benefício

  • Há mais informações em https://wiki.debian.org/ReproducibleBuilds. Parte do conteúdo está desatualizada, mas também há gráficos mostrando quantos pacotes são compilados no CI e quantos deles têm builds reproduzíveis.
    Laranja significa FTBR, isto é, “falha ao compilar de forma reproduzível”. Não sou muito bom em ler números no gráfico, mas eu estimaria algo como alguns por cento, talvez 4~5%

    • Para mim só aparece isto:

      Forbidden

      You are not allowed to access this!
      Até as tags HTML aparecem assim mesmo :)
      Edit: também encontrei a página “I Challenge Thee” no histórico. Será que fui bloqueado por alguma medida anti-bot? Por quê???

  • Ótima notícia. O NetBSD já tem builds totalmente reproduzíveis desde 2017. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

    • Como o próprio link mostra, o NetBSD conseguiu isso com ajuda do Debian. Se entendi corretamente, não foi tanto porque o NetBSD trabalhou mais, e sim porque o problema era mais simples. Há menos pacotes e menos mudanças. Eles ainda usam CVS, então “estabilidade” talvez nem seja uma palavra forte o bastante.
      Aliás, a maior parte dos pacotes do Debian já tem build reproduzível. Os que não têm, algo em torno de 5%, aparecem em laranja neste gráfico: https://wiki.debian.org/ReproducibleBuilds
    • Para me gabar um pouco, o stagex foi o primeiro a alcançar, no ano passado, builds determinísticos e isolados com bootstrap 100% completo a partir do código-fonte, e também o primeiro a exigir, em cada release, várias reproduções assinadas feitas por mantenedores diferentes em seus próprios hardwares.
      O Debian avançou bastante também, mas quando o Debian diz que é reproduzível, isso significa que traz binários de terceiros para fazer seu próprio build. Quando nós dizemos reproduzível, queremos dizer bootstrap 100% a partir do código-fonte até o fim de toda a cadeia de fornecimento de software.
      Acho que essa diferença importa.
      https://stagex.tools

  • Fico realmente feliz com essa mudança. Em 2021, depois de ler sobre o ataque à SolarWinds e ficar chocado, acabei me envolvendo com builds reproduzíveis. [1]
    Acho que a fala de Magnus Ihse Bursie, que trabalhava em builds reproduzíveis do OpenJDK, é a mais apropriada: “Se você me perguntar, o simples fato de compiladores e ferramentas de build terem começado, em algum momento, a produzir saídas não determinísticas já era um bug desde o primeiro dia.” [2]
    [1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
    [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

  • Fico me perguntando por que isso está virando assunto agora. Eu uso Yocto em dispositivos embarcados, e builds reproduzíveis sempre pareceram algo quase trivial de implementar.
    Também dá para ativar facilmente o gerenciamento de pacotes do Debian, então parece que isso já deveria estar resolvido há tempos

    • Fiquei curioso com o que você quer dizer com “por que isso está virando assunto agora”.
      Builds reproduzíveis são uma prática essencial na computação industrial. Em vez de o Debian estar na linha de frente dessa área, isso parece mais um caso de ele adotar uma técnica amplamente usada em toda a indústria, inclusive em outros sistemas operacionais usados em aplicações de longo prazo e relacionadas à segurança.
      Claro, muito do que hoje já usamos com facilidade também se deve ao trabalho difícil feito por Yocto e pelos desenvolvedores do Debian.
      O interessante é que agora os desenvolvedores do Debian estão aplicando isso como uma política mais afirmativa, tornando isso não uma opção, mas a norma padrão
    • A verdadeira questão é se houve verificação ativa de que os builds são mesmo reproduzíveis bit a bit

  • Para amd64 forky:
    reproduced: 97.02%
    good: 17586
    bad: 511
    fail: 30
    unknown: 0
    Essas estatísticas, as de outras arquiteturas e os motivos para a não reprodutibilidade podem ser vistos em https://reproduce.debian.net

  • Sempre me surpreende que o Debian esteja liderando isso e não um fornecedor comercial. Dá a impressão de que grandes organizações que pagam por RHEL e Ubuntu exigiriam binários verificáveis com muito mais força

    • Se um concorrente puder provar que seu pacote é bit a bit idêntico ao que uma grande organização distribui, esse concorrente poderá se beneficiar das garantias de segurança dessa grande organização.
      Isso é ótimo para software livre, mas não é tão bom para quem quer ser monopolista
    • Builds reproduzíveis existem para reduzir a necessidade de confiança, mas fornecedores comerciais estão no negócio de vender confiança

  • Forbidden
    You don't have permission to access this resource.
    Apache Server at lists.debian.org Port 443
    :/
 
GN⁺ 5 시간 전
Opiniões no Lobste.rs

  • É uma boa mudança do ponto de vista de segurança. A transição pode ser trabalhosa, mas no fim vai oferecer mais confiabilidade para usuários de Debian Linux no mundo todo

  • Fico curioso sobre qual é o principal benefício para um projeto como o Debian. A ideia é permitir que todo mundo tenha uma prova de que não há backdoor nos binários?
    Ou seja, reduzir a confiança exigida nos mantenedores e também o risco de mantenedores maliciosos? Não sou cético, só não entendia 100% por que o Debian está investindo tanto tempo nisso. Fazer builds reproduzíveis parece algo bem complicado e trabalhoso

    • Não só backdoors, mas também permite verificar se houve adulteração ou modificação em geral. Isso ajuda na segurança e também traz vantagens para o desenvolvimento do projeto, porque pacotes construídos de forma reproduzível e relativamente isolada têm menos chance de quebrar de forma estranha em ambientes de outros desenvolvedores
      O ponto principal é fornecer um artefato de prova de que o código-fonte que gerou o pacote de saída é realmente aquele código-fonte específico, e não um segundo conjunto oculto de fontes. the reproducible-builds org has a bit of a 'why' which puts it better than i can
      Tornar builds reproduzíveis é muito difícil. Por exemplo, timestamps dentro do pipeline de compilação podem fazer diferença, e o mesmo vale para metadados de arquivos gerados. É preciso eliminar tudo isso e, em alguns casos, o que precisa de patch não é o pacote em si, mas projetos upstream, como CMake ou o compilador Go. Em muitos casos, esse tipo de problema nem era considerado antes, então é necessário trabalhar em toda a stack de build. Dito isso, esse trabalho já vem sendo feito há muito tempo, então boa parte do encanamento de baixo nível já foi concluída ou está bem avançada
    • Não acho que isso deva ser a prioridade máxima do Debian, mas o Debian não funciona assim. As pessoas fazem o que querem fazer, e as prioridades individuais muitas vezes não se alinham bem com o que seria uma prioridade razoável no nível do projeto

  • A reprodutibilidade de que o Debian fala é o mesmo conceito de que falam em lugares como o NixOS?

    • Não. NixOS is not reproducible é o texto de referência padrão
    • Distribuições que acompanham builds reproduzíveis como projeto em geral caminham para o mesmo objetivo. O reproducible-builds.org acompanha projetos que estão trabalhando ativamente nisso em seus pipelines de empacotamento
      O NixOS também está trabalhando em builds reproduzíveis e, se bem me lembro, pelo menos a ISO mínima é 100% reproduzível tanto em build quanto em runtime. Mas a reprodutibilidade de que normalmente se fala no caso do NixOS não é esse tipo de “build reproduzível” discutido aqui. Veja o texto do foxboron linkado em um comentário irmão desta thread. Aquilo está mais próximo de reprodutibilidade de ambiente, ou de “builds determinísticos”, e continua sendo valioso, mas não é disso que estamos falando aqui

  • Por enquanto isso parece um mecanismo de catraca. Coisas que nunca foram compiladas de forma reproduzível ainda vão continuar permitidas?

    • Se um pacote não puder ser compilado de forma reproduzível, ele não será incluído na próxima release do Debian. Ou seja, pacotes que “nunca foram compilados de forma reproduzível” podem continuar no Debian unstable, mas manter no Debian unstable pacotes que não chegam ao stable não é algo bem visto. Ainda assim, pelo que sei, não existe uma regra imposta mecanicamente para isso