Dependência obrigatória de Rust será introduzida no APT do Debian a partir de maio de 2026

• O gerenciador de pacotes APT do Debian passará a incluir código baseado em Rust e suas dependências a partir de maio de 2026
• Na fase inicial, os alvos de integração serão o compilador Rust, a biblioteca padrão e o ecossistema Sequoia
• Os analisadores de arquivos .deb, .ar e .tar, além do código de verificação de assinaturas HTTP, são as principais áreas de melhoria em termos de segurança de memória e fortalecimento dos testes unitários
• Portas sem toolchain Rust precisarão estabelecer um ambiente Rust em até 6 meses ou ter o suporte encerrado (sunset)
• A medida faz parte de uma transição do projeto como um todo para ferramentas e tecnologias modernas, sem ficar travado pela compatibilidade com hardware antigo

---

Plano para introduzir código Rust no APT

• Está prevista a introdução de código Rust e dependência obrigatória (hard dependency) no APT após maio de 2026
  • A adoção ocorrerá depois de maio de 2026, e não será aplicada antes disso
• O escopo inicial de integração ficará limitado ao compilador Rust, à biblioteca padrão e ao ecossistema Sequoia

Objetivo de melhorar qualidade e segurança do código

• O código de parsing de arquivos .deb, .ar e .tar, além do código de verificação de assinaturas HTTP, é o principal alvo da adoção de Rust
  • Foi indicado que essa área deverá se beneficiar bastante de uma linguagem com segurança de memória e de um sistema de testes unitários mais robusto

Exigências para mantenedores de portas

• Portas sem toolchain Rust deverão montar um ambiente Rust em até 6 meses
  • Caso contrário, essa porta poderá ser descontinuada (sunset)

Direção do projeto

• Foi enfatizado que o projeto Debian deve evoluir usando ferramentas e tecnologias modernas
  • Também foi declarado que o avanço não deve ser atrasado por tentativas de se adequar a hardware antigo ou a dispositivos de computação retrô

Outras informações

• O remetente é o desenvolvedor central de Debian e Ubuntu Julian Andres Klode
• O e-mail foi publicado na lista de discussão de desenvolvedores do Debian, debian-devel
• Há um anexo com a assinatura PGP (signature.asc)
• Não há menção a detalhes técnicos adicionais nem a mudanças no cronograma

[GN⁺]

Comentários do Hacker News

• Parece que finalmente chegou a hora. Manter código de parsing de dados não confiáveis em C continua sendo uma dívida técnica que só cresce com o tempo
  Rust também não é muito mais difícil de escrever do que C, e parece a linguagem que surgiria se C fosse recriada hoje refletindo o conhecimento atual sobre design de linguagem e segurança de código
  Se dá para abandonar o suporte a x86 de 32 bits por razões práticas, então o mesmo vale para essas arquiteturas. Se alguém realmente quiser mantê-las, vai ter que criar por conta própria um backend do toolchain Rust

  • Hoje, as linguagens permitidas para aplicações centrais no sistema base são mais ou menos C, C++, Shell(bash), Perl e Python. Python foi adicionada há cerca de 20 anos, e Rust é a primeira linguagem próxima o bastante para substituir o papel do C
    Go foi a mais parecida, mas nunca chegou a ser discutida a ponto de entrar em sistemas centrais como o systemd. Fico curioso se houve debates parecidos quando C++, Python e Perl foram adicionadas no passado
  • Dizem que “os parsers de .deb, .ar, .tar e o código de verificação de assinatura HTTP se beneficiariam de uma linguagem com segurança de memória”, mas fico em dúvida sobre qual ganho real haveria em reescrever em uma nova linguagem códigos já estabilizados ao longo dos últimos 30 anos
    Será que vale mesmo descartar código testado em batalha e criar novos problemas de compatibilidade e bugs?
  • Como abordagem mais prática para resolver problemas de segurança em código C antigo, existe o projeto Fil-C. A ideia é transformar C, na prática, em uma linguagem gerenciada, reduzindo a necessidade de reescrita
  • Isso não é apenas uma questão de segurança de memória. Com o envelhecimento da comunidade C, está ficando difícil encontrar gente para manutenção. Nossa equipe também está migrando todo o código C/C++ para outras linguagens. A maioria dos desenvolvedores C/C++ está na faixa dos 40 anos e não costuma querer trocar de emprego
  • Tenho dificuldade em concordar com a ideia de que Rust é uma recriação moderna de C. Por exemplo, o código do widget de relógio do desktop COSMIC é muito mais difícil de ler do que código C de complexidade parecida, como o GNU coreutils

• Existe uma tendência forte de reescrever sistemas centrais em Rust, mas ainda fico em dúvida se reescrever ferramentas antigas realmente melhora a segurança
  Entendo a dificuldade de introduzir sistemas novos, mas ainda parece que seguimos empilhando camadas sobre decisões de projeto da era do telégrafo

  • Dá para ouvir dois motivos para essas reescritas.
    Primeiro, quase não há novos colaboradores dispostos a lidar com bases antigas em C/C++. Migrar para Rust facilita a entrada de novos desenvolvedores
    Segundo, confiabilidade é validada pelo uso frequente, mas segurança só é validada por ataques. É difícil dizer que código antigo já passou por todos os vetores possíveis. Por isso, há um argumento forte para reforço preventivo de segurança
  • uutils/coreutils usa licença MIT, enquanto GNU coreutils usa GPL, então existe uma diferença de licença. Do ponto de vista das empresas, isso pode ser um ponto importante
  • Alguém precisa aprender, então acho válido reescrever como exercício projetos simples e fáceis de testar. Mas se o resultado vai substituir o original já é outra discussão

• Segundo a thread de e-mails do Debian, Rust já é obrigatório na maior parte das arquiteturas de lançamento do Debian
  No e-mail relacionado, só alpha, hppa, m68k e sh4 aparecem como exceções. Fico curioso sobre o futuro dessas arquiteturas

  • Sinceramente, fico me perguntando se ainda existe alguém usando essas máquinas antigas. A maioria é hardware com mais de 20 anos.
    Rust oferece um alvo Tier 3 para m68k, mas não para as outras arquiteturas. Tenho curiosidade sobre casos reais de uso
  • Segundo Debian Supported Architectures, essas plataformas estão em estado não oficial.
    É surpreendente que elas tenham permanecido enquanto x86 de 32 bits e MIPS saíram. Pessoalmente até sinto certa nostalgia, mas não sei bem onde isso ainda é usado
  • O m68k já tem um port para LLVM, então uma implementação de Rust é possível. Backends LLVM para alpha, hppa e sh4 também teriam valor como material de referência educacional
    No passado o LLVM chegou a ter um backend para DEC Alpha, mas isso faz muito tempo
  • Do ponto de vista do Ubuntu, essas arquiteturas não têm valor comercial
  • São totalmente obsoletas, então podem simplesmente parar na última versão suportada ou criar sua própria distribuição. Adicionar suporte a Rust seria inviável

• Eu gostaria que a comunidade Rust, em vez de se infiltrar em projetos existentes, criasse e provasse diretamente novas tecnologias modernas
  O Redox é um exemplo desse tipo de projeto independente, e é uma pena que esse tipo de tentativa não receba mais impulso

  • Esta é uma decisão oficial do Debian de adicionar a dependência de Rust. Não foi algo imposto por fãs externos de Rust
    Claro, existem fãs mais radicais que dizem “reescreva em Rust”, mas esse caso é diferente
  • ripgrep é exatamente esse tipo de exemplo. Foi criado do zero, e as pessoas realmente gostam dele

• Não tenho problema com usar a biblioteca padrão de Rust, mas não quero puxar 500 pacotes cargo só para compilar um parser simples de deb

• Talvez faça sentido esperar até que o port Rust-for-GCC se estabilize
  O kernel também não pretende tornar Rust obrigatório antes de haver suporte em GCC.
  Com múltiplas implementações, a linguagem tende a ficar menos instável
  Mas, se o suporte a essas arquiteturas for cortado agora, o processo de retorno pode ficar complicado depois, quando houver um toolchain Rust disponível

  • Na prática, essas arquiteturas já estão fora do Debian há mais de 10 anos. Não é esta mudança que vai tirá-las agora
  • Não há suporte oficial, e elas são mantidas por pessoas no tempo livre. Sem que alguma empresa assuma manutenção de longo prazo, será difícil voltar
  • O GCCRS ainda nem consegue compilar o libcore e está no nível do Rust 1.50. Parece que ainda faltam anos para virar um compilador de uso geral
    É mais provável que rustc_codegen_gcc se estabilize antes
  • Os ports não entram nas releases oficiais do Debian e são distribuídos apenas no canal unstable

• Vale lembrar que o autor do e-mail da discussão sobre Rust no Debian é o mantenedor do pacote keepassxc
  Há threads dizendo que ele já teve comportamento ríspido com desenvolvedores upstream e usuários no passado

  • Eu também fui conferir logo depois de ver o e-mail, e acabei rindo ao lembrar da thread antiga
  • Sinceramente, a forma como ele escreve é dura, mas é apenas direta, não insultuosa. Parece drama desnecessário
  • O post no HN em si não é agressivo, mas parece que algumas pessoas estão levando para esse lado
  • Esse tipo de cultura é disseminado no mundo do software livre. Acho que essa tendência de perseguir um usuário idealizado em vez do usuário real vem desde a época do GNOME 3 e da Mozilla

• É interessante ver o processo de mudança de opinião de uma pessoa. Link para declaração anterior

  • É bom ver gente disposta a mudar de ideia com o tempo
  • A adoção de Rust no APT também pode ser uma decisão administrativa, como aconteceu na transição do coreutils

• Acho que Rust é apenas hype. No mundo embarcado, C ainda é rei.
  Nunca vi ninguém ao meu redor realmente usar ou sequer considerar Rust

  • É forçado tirar essa conclusão com base em “não existe no meu entorno”. Também há muitos desenvolvedores embarcados usando Rust
  • Dentro da AWS, serviços centrais como EC2, IAM, DynamoDB e S3 são escritos em Rust.
    Mantém desempenho e eficiência de memória com velocidade alta de desenvolvimento.
    A única desvantagem é o tamanho do binário. Na minha visão, o futuro de Rust já está consolidado
  • Rust também é forte em embarcados, mas o suporte dos fabricantes é fraco, então há muito trabalho inicial específico de hardware.
    Mesmo assim, o atrativo não é só a segurança de memória, mas a qualidade da linguagem e do toolchain como um todo
  • Com avr-rust, esp-rs, cortex-m etc., o ecossistema embarcado também está mudando aos poucos
  • Microsoft, Google e outras empresas também discutem Rust e já o aplicam em produtos reais

• Acho que um ambiente poliglota só cria mais problemas.
  Python, Node, Go, Rust etc. exigem toolchains e gerenciadores de pacotes diferentes, o que aumenta a complexidade
  Eliminar estouros de buffer com Node acabou aumentando os ataques à cadeia de suprimentos.
  Melhor começar do zero, e se a ideia é usar Rust de ponta a ponta, então faz mais sentido contribuir com o Redox OS

  • Na prática, cada linguagem tem vantagens e desvantagens próprias, e o Debian, como SO pragmático, precisa dar suporte a várias linguagens
    Reescrever tudo em uma linguagem só é inviável, e empurrar o Redox também pode acabar sendo ineficiente
    Rust já é uma linguagem suficientemente comprovada e tem valor como linguagem compilada que tem menos chance de se autodestruir ao ser modificada do que C
    Também não é absurdo abandonar arquiteturas antigas
  • Em um projeto grande como o Debian, ampliar as opções é uma decisão razoável. Adicionar Rust é uma escolha perfeitamente compreensível
    Quais linguagens devem sair ou entrar é algo que cabe aos mantenedores do Debian decidir
  • O Linux já desistiu da luta contra a complexidade há décadas