RubyInsights Daily: RubyLLM 2.0 chega em RC, Rails fica Ractor-safe e Active Storage está sob ataque

O mundo Ruby hoje tem uma história que subiu, uma que você deveria resolver antes do almoço e três que mostram para onde a runtime está indo. Segue o resumo do dia 8 de setembro.

RubyLLM 2.0.0.rc1 está no RubyGems

Carmine Paolino publicou o ruby_llm 2.0.0.rc1 hoje. É o primeiro release candidate de uma reescrita que ele detalhou em agosto, e a manchete é arquitetural: providers e protocolos agora são conceitos separados.

Na 1.x, cada provider herdava um formato de API, e por isso adicionar um serviço que falava dois dialetos significava duplicar código. Na 2.0, o provider (OpenAI, Mistral, Vertex AI) é desacoplado do protocolo que ele fala (Chat Completions, Responses, Anthropic). Três coisas decorrem dessa separação:

• A OpenAI agora usa a Responses API por padrão. Modelos de raciocínio conseguem usar tools e extended thinking na mesma chamada, algo que a Chat Completions não conseguia expressar. Dá para voltar ao comportamento antigo por chat ou globalmente.
• Existe um gerador de provider gems. O comando ruby_llm provider-gem Acme --api-base https://api.acme.ai/v1 gera uma gem completa, com CI, testes e gestão do catálogo de modelos, então um provider não precisa mais entrar no core para existir.
• O número de providers vai de 13 para 17, somando Cohere, Ollama Cloud, ElevenLabs e Deepgram, além de um registro público de modelos em rubyllm.com/models.json que atualiza a cada seis horas com preços, capacidades e context windows.

O Ruby mínimo é 3.1.3. É um RC, então trate como tal, mas se você roda RubyLLM em produção, esse é o upgrade para começar a ler agora e não daqui a um mês.

Atualize o Active Storage hoje, se ainda não atualizou

A CVE-2026-66066, apelidada de KindaRails2Shell, é uma leitura arbitrária de arquivos no Active Storage com CVSS 9.5 que pode escalar para exposição de segredos, RCE e movimentação lateral. Foi divulgada em 29 de julho, e a SecurityWeek relata que já está sendo explorada ativamente, cerca de um mês depois dos patches. A VulnCheck contou aproximadamente 7.000 instâncias vulneráveis expostas no início de agosto.

A causa raiz é que o Active Storage não desabilitava operações perigosas do libvips antes de processar arquivos enviados pelo usuário. Se você aceita upload de imagens e usa o processador de variantes Vips, você está no escopo.

Versões corrigidas:

Rails 6.0.0 até 6.1.7.10 também podem ser afetados quando o Active Storage usa Vips, e não houve correção publicada para esses branches. Atualizar a gem não é o serviço completo: garanta que o libvips esteja na 8.13 ou superior, defina VIPS_BLOCK_UNTRUSTED (ou chame Vips.block_untrusted(true)) como controle temporário e rotacione tudo que a leitura de arquivos poderia ter vazado, começando por secret_key_base, credentials e chaves de storage. O patch sozinho não desfaz o vazamento de um segredo que já foi lido.

O Rails está ficando Ractor-safe, um objeto de configuração por vez

O This Week in Rails de 4 de setembro é quase inteiramente um changelog de Ractor. Mergeados nesta semana: configuração de controller compartilhável entre Ractors (#58647), configurações do Action View (#58620), callbacks de commit do Active Record (#58653), configuração de time zone (#58642), uma correção para o schema context não travar em deadlock ao inicializar atributos (#58651) e armazenamento por Ractor para event reporters fora do Ractor principal (#58599).

Nenhum deles é empolgante sozinho. Juntos, são o trabalho sem glamour que precisa acontecer antes de Ractors serem usáveis em uma aplicação Rails real, e é o sinal mais claro até agora de que o framework pretende chegar lá em vez de deixar a concorrência a cargo de threads e processos.

Dois merges não relacionados a Ractor que valem menção no mesmo digest: fetch_multi agora devolve as chaves na ordem original em vez de reordená-las, o que silenciosamente corrige uma classe de bugs sutis de cache, e o adapter do PostgreSQL passa a aceitar a opção error_verbosity.

ZJIT faz inline do fastpath de alocação do GC

Peter Zhu publicou um walkthrough no Rails at Scale sobre ensinar o ZJIT a fazer inline da alocação de objetos em vez de chamar C a cada new. O GC entrega ao ZJIT seu cursor e limite de alocação, o JIT emite uma alocação por bump pointer inline e só cai no caminho em C quando isso falha.

O benchmark de alocação de hash vai de 117,2 ms para 66,4 ms, cerca de 1,77x, com ganhos de 2x a 3x relatados em outros tipos. A variante para arrays (ruby/ruby#17277) foi mergeada na master em julho, com aproximadamente 1,5x na alocação de array vazio. Isso está na branch principal, não em uma release estável, mas alocação é caminho quente em praticamente toda request Rails, então vale acompanhar.

Fable 5.1 assume a liderança do Agents on Rails

O [relatório de benchmark de 2 de setembro](https://rubyonrails.org/2026/9/2/agents-on-rails-claude-