A Canonical não está reescrevendo todo o Ubuntu em Rust, mas começou a substituir componentes essenciais do sistema em pontos nos quais considera que os ganhos de segurança de memória e manutenção justificam o custo da transição. Segundo o que foi apresentado por Jon Seager, vice-presidente de engenharia da Canonical, durante uma transmissão organizada pela JetBrains, a decisão faz parte de uma visão de longo prazo para uma plataforma que opera cerca de 15 milhões de implantações em servidores, computadores desktop, dispositivos de borda e dentro de carros.
A iniciativa parte de uma pergunta sobre o que o Ubuntu precisará nas próximas duas décadas, e não de uma campanha para reimplementar todas as ferramentas existentes. A Canonical considera que Rust oferece um conjunto de ferramentas convincente para o desenvolvimento de sistemas, especialmente quando a resistência a erros de memória e a confiabilidade são fatores relevantes em softwares executados dentro de sistemas industriais, carros ou infraestruturas sensíveis.
Substituições seletivas em vez de uma reescrita abrangente
Os primeiros desses componentes chegaram ao Ubuntu 26.04 LTS. O uutils coreutils, uma reimplementação das ferramentas GNU coreutils em Rust, tornou-se a opção padrão, com o objetivo declarado de alcançar compatibilidade completa com o comportamento das ferramentas GNU. Isso significa que uma pequena diferença de comportamento não é necessariamente tratada como uma melhoria, mas pode ser considerada um erro se quebrar um script ou uma ferramenta que dependa do comportamento antigo.
Já o sudo-rs segue um caminho diferente. Em vez de buscar compatibilidade total com o sudo, o projeto repensa o formato de uma ferramenta de concessão de privilégios caso ela fosse projetada hoje, após décadas de experiência em segurança. Entre as mudanças que provocaram reações fortes está a exibição, por padrão, de asteriscos ao digitar a senha no terminal. A Canonical afirma aceitar essas mudanças intencionais mesmo quando causam atrito no curto prazo, pois as considera parte de um novo design, e não apenas uma cópia alternativa compatível.
Tempo e certificados dentro do escopo da mudança
O próximo projeto é o ntpd-rs, cujo financiamento a Canonical anunciou em junho de 2026 por meio da Trifecta Tech Foundation, com o objetivo de torná-lo a ferramenta padrão de sincronização de tempo no Ubuntu. O plano é arquivá-lo no Ubuntu 26.10 e, depois, fazer a transição completa para ele como opção padrão no Ubuntu 28.04, substituindo gradualmente chrony e linuxptp por meio de uma única ferramenta compatível com NTP, NTS e PTP.
A importância dessa mudança decorre do fato de que a sincronização precisa de tempo não se limita a servidores de rede. Ela afeta os microcontroladores dentro de aeronaves, carros e robôs, os sistemas criptográficos que alternam chaves periodicamente e também os sistemas que dependem de localização. O material explica que usar chrony e linuxptp em conjunto pode exigir a configuração de várias ferramentas e fontes de tempo, enquanto o ntpd-rs pretende reunir essas funções em uma única ferramenta e um único arquivo de configuração, aproveitando a segurança de memória.
O projeto UPKI difere dessas substituições por ser um projeto novo, desenvolvido do zero em colaboração com o projeto Rustls, e por ter como objetivo adicionar a verificação de revogação de certificados às ferramentas do sistema no Linux. A Canonical pretende que ele chegue primeiro ao Ubuntu 26.10. A ideia está relacionada a ferramentas como curl, wget e OpenSSL, nas quais, segundo o material, esse tipo de tratamento da revogação de certificados não foi integrado da mesma forma que nos navegadores.
O que muda, na prática, para os usuários?
A Canonical escolheu os limites das versões LTS para introduzir essas mudanças, porque as organizações normalmente atualizam seus sistemas nesses momentos e porque a existência de um caminho de reversão é importante ao mudar ferramentas de baixo nível. O material afirma que as versões anteriores receberão suporte gerenciado por 15 anos e que as ferramentas antigas permanecerão no arquivo, de modo que o novo comportamento não seja imposto a um sistema de produção existente sem a opção de retornar.
Mas a compatibilidade não é uniforme entre os projetos. O uutils coreutils enfrentou um exemplo prático quando a ferramenta head retornou um erro ao solicitar a leitura de uma quantidade de bytes de um arquivo vazio, enquanto o GNU coreutils retornava zero. Essa diferença quebrou um script oculto dentro do pacote snap do Obsidian, e o comportamento foi alterado para corresponder ao GNU. O exemplo mostra que a segurança de memória não elimina a importância da compatibilidade com pressupostos acumulados em torno das ferramentas antigas ao longo de 30 anos.
O desafio não termina na escrita do código
Introduzir Rust em uma distribuição grande também exige lidar com a cadeia de dependências, compilação e distribuição. A Canonical adota uma abordagem que agrupa os crates de cada pacote em um único arquivo, em vez de empacotar cada crate como um pacote deb separado. Segundo o material, isso ajuda a manter a superfície de dependências gerenciável e a tornar os processos de compilação determinísticos, embora não reproduzíveis no sentido formal.
No início de 2026, o cargo auditable foi implantado em todos os pacotes Rust do arquivo do Ubuntu. Cada binário Rust contém uma SBOM incorporada que registra os nomes e as versões dos crates usados na compilação e é atualizada automaticamente quando o pacote é recompilado. Esses dados não impedem vulnerabilidades, mas tornam mais direto identificar as versões afetadas quando um problema é descoberto em uma das dependências.
Leitura da certi.news: a verdadeira mudança aqui não é apenas substituir ferramentas escritas em C por outras escritas em Rust, mas introduzir uma camada de segurança, manutenção e rastreamento de dependências em componentes difíceis de modificar depois de disseminados. Em contrapartida, os exemplos de compatibilidade e o comportamento do sudo-rs revelam que a transição pode impor decisões de design percebidas pelos usuários e que seu sucesso dependerá tanto do gerenciamento dessas diferenças quanto da linguagem de implementação. As datas anunciadas para o ntpd-rs e o UPKI continuam sendo metas futuras, enquanto a fonte demonstra que o escopo da mudança é seletivo e que as ferramentas antigas e as opções de reversão continuam fazendo parte da estratégia da Canonical.