O mundo do software livre está testemunhando uma mudança importante, com a lendária distribuição Debian se preparando para integrar a linguagem Rust em seu coração: o gerenciador de pacotes APT.
Em uma comunicação recente na lista de e-mails de desenvolvedores, Julian Andres Klode, mantenedor principal do APT confirmou que o projeto planeja introduzir dependências obrigatórias de Rust a partir de maio de 2026. Essa decisão alinha o Debian com práticas modernas de desenvolvimento, focadas em segurança e confiabilidade.
A mudança fará com que o compilador Rust faça parte da infraestrutura central de gerenciamento de pacotes do Debian, concentrando-se inicialmente em áreas críticas de baixo nível, como a análise e o parsing dos arquivos importantes como .deb, .ar, .tar, além da verificação de assinatura HTTP.
A decisão traz consigo um aviso importante para os mantenedores de portes do Debian que ainda não possuem um toolchain Rust funcional. Klode os incentivou a garantir o suporte total ao Rust nos próximos seis meses ou considerar o fim do suporte oficial a esses portes (sunsetting).
Isso significa que arquiteturas incapazes de compilar código Rust não serão mais suportadas oficialmente após o início da transição, marcando um movimento significativo para o projeto Debian como um todo.
Ao incorporar Rust ao APT, a distribuição se junta a um crescente número de grandes projetos de código aberto que estão gradualmente adotando essa linguagem, incluindo o kernel Linux, o Firefox e o systemd.
Tudo indica que esta é apenas uma das primeiras etapas rumo a uma integração ainda mais profunda do Rust nesta que é uma das mais importantes distribuições Linux.
Me pergunto qual o “modelo de ameaça” que justifica esse esforço. Rust não defende contra erros de lógica – contra os quais o APT atual está há anos se defendendo no “mundo real” – e “memory safety” não vai impedir o usuário de concordar em instalar um trojan.
Rust tem duas características ele é seguro em termos de acessar endereços errados e erros em runtime são do tipo panic, isso significa que todo aplicativo em Rust a não ser uma falha na própria linguagem sem a saída rastreável, teoricamente é o fim de pacotes com a falha reinst req (corrupção no /var/lib/status quando o APT morre no meio do caminho do nada), o próprio APT ao menos em tese deveria dar conta de resolver minimizado a necessidade de intervenção manual
Tudo ja que quem da as ordens e a canonical, so olhar a quantidade de funcionários e os liderantes que trabalham na canonical e são contribuidores do mesmo.
É que no caso o APT e o Debian não são feitos pela Canonical. Eles serão afetados por usarem o APT também, mas o problema, por assim dizer, não tem a ver com a empresa.
E bem, se isso se tornar um grande problema, e não for consertado, há outros que não parecem, até onde sei, terem adotado o rust. Zypper, pacman, dnf, por exemplo.
Me parece muita tempestade em copo d’água, embora inche o tamanho do pacote final em uns 20 MB do ponto de vista do usuário o que realmente impacta é que antes o apt era:
#!/usr/bin/env bash
# Dá ruim se der qualquer erro
set -o errexit
# Dá ruim se acessar a variável errada
set -o nounset
# Seja irritantemente verboso se der erro
set -o -o xtrace
# Seja irritantemente transparente sobre o que está fazendo
pode_dar_errado;
escreve_muita_coisa;
pode_dar_muito_errado;
escreve_ainda_mais_coisa;
executa_um_monte_de_comando_arbitrario;
pode_ferrar_com_o_arquivo_de_estatus;
escreve_uma_mensagem_feliz;
E se tornou com Rust:
#!/usr/bin/env bash
# Dá ruim se der qualquer erro
set -o errexit
# Dá ruim se acessar a variável errada
set -o nounset
# Seja irritantemente verboso se der erro
set -o trace
# Seja irritantemente transparente sobre o que está fazendo
set -o xtrace
trap EXIT verifique_se_o_arquivo_de_estado_esta_OK_antes_de_sair;
. /monte/de/biblioteca/rust.sh
pode_dar_errado;
escreve_muita_coisa;
pode_dar_muito_errado;
escreve_ainda_mais_coisa;
executa_um_monte_de_comando_arbitrario;
pode_ferrar_com_o_arquivo_de_estatus;
escreve_uma_mensagem_feliz;
Ou seja, é uma mudança positíva, tudo vai funcionar exatamente igual é agora mas para os devs muda que eles não precisam mais se preocupar com classes inteiras de bugs
Ainda temos SIGKILLs, quedas de energia e funções fora do Rust (que com certeza vão estar envolvidas aqui, especialmente se reescrita for gradual/parcial) para causar isso.
A solução preferível seria um formato mais robusto, ou um comportamento, por me faltar palavra melhor, mais “lógico” ao encontrar pacotes quebrados, que não exija intervenção com o dpkg.
pra mim, que sou um reles mortal em programação e só sei fazer script bash com ajuda do chatgpt, desde que que o apt cumpra seu papel, não me importa o que venha no pacote. creio que para os demais usuários, seja isso também.
A falha do arquivo de estado ficar corrompido tem nada a ver (ou muito pouco a ver) com a segurança do código. Já estamos numa época onde é possível atualizar os arquivos de forma atômica, então o problema passa a ser “como eu mantenho o arquivo de estado de forma íntegra mesmo durante uma atualização”? Não tenho conhecimento de muitos gerenciadores de pacotes, mas no gentoo eu jamais vi o sistema entrar em um problema desse tipo. Obviamente a resolução de dependências é muito mais lenta, até pelo gerenciador ser feito em python, mas aí entra prioridades de programação: Até que ponto a velocidade da resolução/instalação é mais importante do que evitar que o gerenciador de pacotes entre em estado de inconsistência?
E se for esse mesmo o problema (manter consistência do arquivo de estado), seria possível resolver em C++? Seria possível resolver mantendo a atual lógica? Eu imagino que seria sim possível, mas seria mais fácil resolver a questão em Rust?
In particular, our code to parse .deb, .ar, .tar, and the
HTTP signature verification code would strongly benefit
from memory safe languages and a stronger approach to
unit testing.
Na prática, são objetivos bem conservadores e realistas. Por exemplo, um dos objetivos, eliminar casos como CVE-2015-0860, CVE-2020-27350, CVE-2020-3810. E não é só o APT que sofre com isso, por exemplo: CVE-2024-20697.
Estamos falando de uma etapa (parsing) que gera insumos que serão executados com privilégio root (scripts de mantenedor, etc). Historicamente, esse tipo de parsing de fronteira é uma fonte relevante de bugs severos, especialmente na classe RCE, e muitos dos casos caem na família de erros de corrupção de memória.
update: Havia sugerido CVE-2019-3462 e CVE-2022-1664 como exemplo, mas estes caem na família de erros de lógica de negócio. Adicionei alguns outros exemplos que encontrei e se enquadram.
Os objetivos são bem simples mesmo, o principal deles, é evitar erros de corrupção de memória no APT.
Honestamente, hoje em dia não é nada fácil explorar corrupção de memória para rodar código malicioso, mas meramente provocar falhas em atualizações ou fazer o APT consumir quase toda a RAM, já é um problema bastante desagradável.
Às vezes pensamos apenas no caso mais tipico de uso que vemos aqui, um usuário de computador, mas o APT pode estar rodando em uma geladeira inteligente, ou em um contêiner importante por aí. A atualização falhar em casos assim é um problema mais complexo.
E sendo criativo, alguém malicioso, por qualquer que seja o motivo, pode gerar todo tipo de dor de cabeça, explorar a falha para entupir a memória RAM, ou a memória persistente do aparelho.
Enfim, melhor não ter erros de corrupção de memória.
