Rust 1.100: Cargo ganha cooldown de dependências e aviso de crate não usada

Rust 1.100: Cargo ganha cooldown de dependências e aviso de crate não usada

O Rust 1.100.0 saiu nesta quinta-feira, 12 de novembro, e o número redondo é a parte menos interessante do anúncio. O que muda de verdade para quem mantém código em produção está no Cargo, e são duas mudanças de processo: uma idade mínima de publicação para dependências (o global-min-publish-age , apelidado de cooldown) e um aviso nativo para crates declaradas no Cargo.toml que o código nunca usa.

As duas coisas parecem pequenas e não são. Cooldown resolve um problema que todo gerenciador de pacotes passou a enfrentar em 2026: a janela entre uma versão maliciosa ir ao ar e alguém removê-la é curta, e quem instala no minuto zero é justamente quem pega o pacote. Já o lint de dependência não usada ataca o passivo silencioso do Cargo.toml — a crate que ninguém lembra por que está ali, mas que continua sendo compilada, escaneada e eventualmente comprometida.

Nenhuma das duas está ligada por padrão. Quem não mexer na configuração não verá diferença nenhuma depois do rustup update stable .

Como o cooldown funciona

A regra é simples: uma versão publicada há menos tempo que o limite configurado deixa de ser candidata na resolução de dependências. O cargo update passa a ignorar lançamentos recentes e escolhe a versão mais nova que já passou da janela.

Vale checar o nome exato da tabela e o formato da duração no Cargo Book da sua versão antes de commitar — é uma chave nova e a documentação manda mais que qualquer blog. A propriedade importante, porém, é estável: a idade é contada a partir do timestamp de publicação que o índice do registry informa, e é possível definir idades diferentes por registry, o que faz diferença quando a empresa espelha crates.io num registry interno e quer política mais dura no espelho.

Três detalhes de comportamento importam mais que o número escolhido:

É opt-in e é silencioso. Sem configuração, nada muda. E em toolchains anteriores a 1.100 a chave é simplesmente ignorada — o arquivo não quebra o build de quem está em versão anterior, mas também não protege ninguém.

Não desfaz o que já está no Cargo.lock . Versões já travadas continuam sendo resolvidas. O cooldown age sobre escolhas novas, não sobre o histórico do lockfile.

cargo install ignora o cooldown. Quem instala ferramentas de linha de comando com cargo install continua pegando a versão mais recente na hora. Ou seja: a proteção vale para o build do seu projeto, não para o seu ambiente de trabalho.

Onde o cooldown briga com a correção de segurança

Esse é o ponto que mais passa batido, e ele já apareceu em outros ecossistemas. O Composer 2.11, no PHP, ativou um cooldown parecido e, combinado com o bloqueio de versões com vulnerabilidade conhecida (ligado por padrão desde a 2.10), criou um impasse: a versão antiga é recusada pelo advisory, a versão corrigida é recusada pela idade. O composer update simplesmente falha.

No Cargo o risco é o mesmo em outra roupa. Durante o beta da 1.100, relatos mostraram cargo update rebaixando uma correção de segurança forçada, justamente porque a versão corrigida era nova demais para a janela configurada. A saída é o caminho explícito, que continua existindo:

A recomendação prática, então, é não tratar o cooldown como política única. Ele é uma segunda camada sobre cargo audit , cargo deny e revisão de advisory — não um substituto. E o valor precisa ser escolhido pensando no tempo médio que o time leva para reagir a um RUSTSEC: se a resposta é rápida, 24 a 72 horas já filtram o grosso dos pacotes maliciosos de vida curta; sete dias é confortável para produção, mas aumenta o tempo em que o build fica exposto a uma falha já divulgada.

O lint de dependência não usada e o CI

A segunda mudança é mais mundana e mais fácil de colher ganho imediato: o Cargo passa a avisar quando uma crate está declarada no Cargo.toml e não aparece em lugar nenhum do código. O detalhe que engana é o CI. Rodar cargo clippy -- -D warnings continua saindo com código 0, porque o aviso vem do Cargo, não do rustc. Para transformar em falha de build:

O lint não é onisciente: há dependências que ele não consegue atribuir a código de forma confiável, então em monorepos grandes vale comparar com o cargo-machete antes de sair apagando linhas. O ganho real não é estético — cada dependência removida é uma atualização a menos, um advisory a menos e uma superfície a menos para um build script malicioso executar no seu CI.

Riscos e custos de adoção

Determinismo aparente. Times que fixam versões por data e depois reclamam de build diferente entre máquinas descobrem que o cooldown é mais uma fonte de variação, porque ele depende do horário em que o índice foi consultado.

Feature flags e builds condicionais. Dependência usada apenas sob certa feature pode gerar falso positivo no lint se o CI só compila o perfil padrão.

Política sem dono. Configuração de dependência espalhada por repositório vira folclore. Em ambientes com várias stacks — Python, Node.js, .NET e Angular convivendo no mesmo pipeline, cenário comum nos projetos que a Maquinaweb desenvolve —, o cooldown do Cargo precisa da mesma governança que o package-lock , o Directory.Packages.props e o requirements.txt .

O que eu faria nesta semana

Subir para 1.100 e ativar global-min-publish-age = "3 days" no .cargo/config.toml versionado do repositório, não na máquina de cada um.

Ligar CARGO_BUILD_WARNINGS: deny primeiro num job informativo, por duas ou três semanas, antes de tornar bloqueante.

Escrever no CONTRIBUTING o procedimento de exceção: quando há RUSTSEC, o cargo update --precise é permitido e registrado no PR.

Se o seu time está discutindo como padronizar política de dependências, migrar stack ou estruturar um projeto novo com processos de build que aguentem auditoria, o time da Maquinaweb pode ajudar a colocar isso no papel e no pipeline.

Fontes