Bug de data no coreutils baseado em Rust interrompe atualizações automáticas no Ubuntu 25.10

• No Ubuntu 25.10, um bug no comando date do coreutils (uutils) escrito em Rust fez com que a função de atualizações automáticas deixasse de funcionar em alguns sistemas
• O bug foi encontrado no pacote rust-coreutils versão 0.2.2-0ubuntu2 ou anterior e foi corrigido na versão 0.2.2-0ubuntu2.1 ou posterior
• O problema afetou implantações em nuvem, imagens de contêiner, instalações desktop e de servidor, mas não afetou atualizações manuais via comando apt
• Nesta versão, o Ubuntu está testando a migração para utilitários baseados em Rust (uutils, sudo-rs), como parte da avaliação para uma possível adoção na versão de suporte de longo prazo (LTS) do próximo ano
• O incidente mostra a necessidade de validar a estabilidade durante a transição para Rust e traz implicações importantes para futuras estratégias de segurança e manutenção da distribuição

---

Visão geral da falha nas atualizações automáticas do Ubuntu 25.10

• O projeto Ubuntu anunciou oficialmente que, devido a um bug no comando date do uutils baseado em Rust, alguns sistemas não conseguiam verificar atualizações automaticamente
  • Entre os sistemas afetados estavam ambientes de implantação em nuvem, imagens de contêiner, instalações do Ubuntu Desktop e Ubuntu Server
  • Como a verificação automática de atualizações falhava, havia risco de atraso na aplicação de patches de segurança e atualizações de software
• A equipe de segurança do Ubuntu publicou um aviso com instruções de correção (remediation instructions)
  • Os usuários precisam atualizar o pacote rust-coreutils para a versão 0.2.2-0ubuntu2.1 ou posterior para resolver o problema
  • O bug afeta apenas o processo de atualização automática e não impacta o comando apt nem outras ferramentas de atualização manual

Causa do bug e escopo do impacto

• A causa do problema foi atribuída a um erro no tratamento da hora do sistema pelo comando date do coreutils reescrito em Rust (uutils)
  • Com isso, o agendador de atualizações automáticas não conseguia calcular a data corretamente, interrompendo a rotina de verificação de updates
• O impacto se estendeu a todos os formatos de distribuição do Ubuntu 25.10, com potencial de interrupção operacional principalmente em ambientes de servidor automatizados e instâncias em nuvem
• Com esse problema, o Ubuntu reconheceu a necessidade de reforçar os procedimentos de validação de estabilidade dos utilitários de sistema baseados em Rust

Transição para utilitários baseados em Rust (projeto “Oxidize”)

• No lançamento do 25.10, o Ubuntu está conduzindo o projeto “oxidize”, um experimento para substituir o coreutils tradicional em C pelo uutils baseado em Rust
  • Ao mesmo tempo, também está introduzindo a versão em Rust do comando sudo (sudo-rs), com o objetivo de melhorar segurança e memory safety
• O projeto funciona como uma etapa de teste para avaliar se os utilitários baseados em Rust poderão ser incluídos na versão LTS prevista para abril de 2026
• A LWN já havia tratado do projeto em março de 2025, analisando o impacto da adoção de Rust na estabilidade estrutural das distribuições Linux

Versão corrigida e orientações de resposta

• Segundo o aviso de segurança do Ubuntu, o problema está presente no rust-coreutils 0.2.2-0ubuntu2 ou anterior
  • Ao atualizar para a versão 0.2.2-0ubuntu2.1 ou posterior, o bug é corrigido
• Os usuários podem fazer a atualização manual dos pacotes com o comando apt update && apt upgrade
  • Até que a função de atualização automática seja restaurada, recomenda-se fazer verificações manuais regulares

Implicações e perspectivas futuras

• O incidente é visto como um exemplo da instabilidade inicial no processo de transição para Rust
  • Ele sugere que a adoção de Rust para melhorar memory safety e segurança precisa vir acompanhada de validação da estabilidade funcional
• O experimento do Ubuntu pode acelerar a tendência de adoção de Rust em distribuições Linux de forma mais ampla
• Se os utilitários baseados em Rust forem integrados de forma estável em futuras versões LTS, espera-se uma melhora na segurança do sistema e na eficiência de manutenção

[GN⁺]

Comentários do Hacker News

• Acho aceitável descobrir problemas cedo desse jeito
  Desde que isso seja resolvido antes da versão LTS, não vejo problema

  • Como usuário comum do Ubuntu, não tenho certeza se isso é realmente aceitável
    O gráfico de compatibilidade de testes do uutils/coreutils mostra que ainda não está completo
    Em especial, o date passa em apenas 2 testes, pula 3 e falha em 3
    Nesse estado, acho difícil considerar isso pronto para produção
  • Quando você opera vários sistemas, passa a confiar tanto em alguns componentes que nem pensa em suspeitar deles quando algo dá errado
    Esse tipo de bug pode parecer pequeno para um usuário individual, mas em ambientes de grande escala é crítico
    Passei o dia inteiro depurando para no fim descobrir que o sistema estava enviando dados para um lugar explicitamente proibido
    No fim, o sistema inteiro parou, e quando uma ferramenta da qual você depende quebra, administrar tudo fica realmente difícil
    Se fosse qualquer outra linguagem que não Rust, os desenvolvedores teriam sido duramente criticados
  • Não dá para dizer que está tudo bem quando utilitários centrais são trocados por versões reescritas sem uma razão clara, e elas são tão instáveis que uma distribuição estável nem consegue se atualizar direito
  • “É assim que se encontram problemas” soa como uma resposta ao estilo Microsoft /s

• Fico me perguntando se o coreutils existente tinha problemas grandes o suficiente para justificar melhorias

  • Talvez seja por questões de licença. Já houve essa especulação neste comentário antes
  • Do ponto de vista de mantenedores do OpenBSD, implementar o coreutils em uma linguagem é essencial para julgar se ela é adequada como linguagem de sistema
    Texto relacionado: lista de discussão do OpenBSD
  • Também pode ser por questões de segurança, como a CVE-2015-4042
  • Parece que o problema era não ter sido escrito em Rust. Mas então fica a dúvida de por que o borrow checker não pegou o bug do date
  • Se quiser entender o contexto, vale ler o texto oficial do Ubuntu: Carefully but purposefully oxidising Ubuntu

• Queria encontrar o link do patch no uutils

  • O artigo da LWN explica isso
    O bug principal é que o suporte a date -r <file> não estava implementado, mas o Ubuntu integrou essa versão mesmo assim
    O comando simplesmente ignorava a opção -r em silêncio e não fazia nada
    Itens relacionados: #8621, PR #8630
  • O relatório de bug do Ubuntu está aqui
  • Acho que a raiz do problema é a própria existência do projeto de reescrita em Rust
  • É uma pena que falte uma explicação mais concreta do problema real
    O último commit (link) corrigia o parsing de date para corresponder ao GNU, mas pelos outros comentários talvez a causa não tenha sido essa

• Gostei do comentário principal — “o próximo nome de release do Ubuntu vai ser Grateful Guinea-Pig”

• Pelo changelog do Ubuntu, o bug está ligado ao date -r
  Pelos links do changelog, do relatório de bug, da issue e do PR,
  o date -r deveria exibir o horário de modificação do arquivo, mas a versão em Rust simplesmente ignorava isso
  Essa ausência de comportamento básico é decepcionante para um projeto que se apresenta como “substituto seguro”

  • Se essa versão realmente passou na suíte de testes oficial do coreutils, então isso talvez signifique que a suíte de testes está incompleta
  • Mas pelo menos não houve buffer overflow!

• Aviso de segurança do Ubuntu — parece um caso típico

• Tive a sensação de que o Ubuntu 25.10 estava inutilizável. Foi a primeira vez que disse isso de uma versão não LTS

  • Fiquei curioso para saber o que exatamente foi tão grave assim

• Concordo com a ideia de que “reescrever em Rust utilitários em C validados por décadas pode ser bom no longo prazo, mas os problemas de curto prazo eram previsíveis”
  Mas fico na dúvida sobre quão longo é esse “longo prazo”
  Numa apresentação na FOSDEM, um desenvolvedor do uutils alegou desempenho melhor com benchmarks incorretos, quando na prática isso se devia à falta de suporte a locale, o que também foi problemático
  Links relacionados: apresentação da FOSDEM, thread 1, thread 2

  • Mas essas ferramentas centrais também são, no fim, resultado de várias reescritas ao longo do tempo. Não precisa enxergar isso de forma tão extrema
  • Depois que o tratamento de locale foi adicionado, há até um artigo da Phoronix dizendo que o desempenho melhorou
  • Em vez desse tipo de reescrita, talvez o mesmo esforço tivesse sido melhor empregado na criação de um sistema de verificação formal, do ponto de vista de segurança
  • Às vezes projetos open source também são usados como forma de construção de reputação pessoal
    Reescrever utilitários essenciais traz bastante vantagem para o portfólio

• Tenho curiosidade sobre o estado da arte em guided state-space exploration e fuzzing
  Se já existe uma implementação anterior, parece que um fuzzer poderia comparar o comportamento das duas versões para fazer uma verificação white-box

  • Acho que property testing combina bem com um caso desses
    Dá muito trabalho escrever proptests para o espaço inteiro de entradas, mas se os argumentos de CLI forem estáveis, isso parece perfeitamente viável
    Também daria para gerar casos automaticamente com base em materiais como páginas man
    Em Rust, eu usaria o crate proptest; para validar diferenças de CLI, Python com Hypothesis via chamadas externas também parece uma boa opção