Confiar cedo demais no KDE Plasma, no Claude Code e no Guix

Quando um programa pode mentir sobre quem é, atalhos comuns viram um lugar estranho para confiar. Hoje o primeiro tropeço cabe num clique bem normal: abrir uma nova janela no KDE Plasma.

KDE Plasma usou identidade fraca e deixou um Flatpak sair do sandbox

Flatpak existe para colocar limite. O app roda num ambiente mais apertado, com permissões declaradas, e o sistema tenta impedir que ele alcance partes do host que não deveria tocar. O problema descrito por Kimiblock aparece quando o desktop precisa responder a uma pergunta simples: qual app é este?

Segundo a análise, o KWin conseguia associar uma janela a um app usando dados de identidade vindos da linha de comando do processo, em estilo /proc/PID/cmdline. Só que essa identidade é mutável. Um processo sem privilégio pode tentar se apresentar com outro argv0, e aí o desktop corre o risco de acreditar na etiqueta grudada pelo próprio suspeito.

O gatilho de usuário é bem cotidiano. A pessoa clica em Open New Window ou usa o clique do meio no ícone da barra de tarefas. A partir daí, um Flatpak malicioso, mesmo com permissões mínimas, podia fazer o Plasma abrir um binário do host fora do sandbox e fora do namespace de montagem do app.

O recorte é local: uma fuga de sandbox acionada por interação do usuário e por uma decisão ruim de identidade no shell do desktop. Ainda assim, é grave para quem usa Linux no desktop, empacota apps ou confia em sandbox como fronteira operacional.

A linha do tempo do autor também pede cuidado: relato inicial em 1 de abril, PoC em 2 de abril, problema ainda observado no Plasma 6.7 Beta em 2 de maio e publicação depois de 90 dias. A fonte não traz CVE nem confirma correção na sua distro. O caminho sensato é acompanhar KDE/Plasma na distribuição que você usa e tratar “linha de comando do processo” como evidência fraca de identidade.

Fontes: Kimiblock e Phoronix.

Claude Code marcou prompts quando o endpoint deixava de ser o padrão

Na quarta-feira, Claude Code apareceu por aqui no contexto de agente rodando setup de repositório desconhecido. Agora a camada é outra: o próprio cliente, o endpoint configurado e o texto invisível que vai junto no prompt do sistema.

O pesquisador Thereallo analisou o Claude Code 2.1.196 e descreveu um marcador escondido na string de data do prompt do sistema. O comportamento aparece quando ANTHROPIC_BASE_URL aponta para um endpoint customizado, como proxy, gateway interno, roteador de modelos ou caminho de revenda. No endpoint oficial padrão da Anthropic, a fonte descreve um caminho de retorno antecipado.

O marcador não aparece como um campo explícito dizendo “este pedido veio de tal lugar”. Ele muda pontuação e formato da data, de um jeito visualmente comum. A análise cita checagens de fuso como Asia/Shanghai e Asia/Urumqi, além de listas de hostnames e palavras ligadas a laboratórios de IA. Essas listas, segundo a fonte, estavam codificadas em base64 e decodificadas com XOR usando a chave 91.

O cuidado principal é separar o mecanismo observado da história corporativa que cresceu em volta dele. A intenção, a explicação interna e o cronograma de remoção não estão confirmados pela fonte primária. Circularam versões falando em confirmação de engenheiro da Anthropic, experimento de março e remoção em 1 de julho; sem uma fonte primária para isso, o fato sólido é o marcador observado.

A fonte também não comprova malware nem vazamento de privacidade. O próprio autor trata a implementação como esquisita, não necessariamente maliciosa. O incômodo é outro: uma ferramenta de código que pode mexer com shell, arquivo e rede precisa deixar classificação de endpoint e política de telemetria explícitas. Se a informação vai escondida em pontuação de data, a confiança fica mais difícil de auditar.

Fontes: Thereallo e Hacker News.

Guix corrigiu a etapa em que baixava primeiro e verificava depois

O Guix publicou em 2 de julho um aviso oficial para falhas em guix substitute, guix pull, guix time-machine e guix-daemon. O detalhe que dói é antigo em espírito: assinar e verificar ajuda, mas verificar depois de escrever dado controlado pelo atacante pode chegar tarde.

No caso de substitutos binários, o sistema podia extrair dados do archive durante o download antes da verificação completa do hash. A fonte também fala em problemas ligados a narinfo, restore-file e URI file://. HTTPS não fechava essa porta específica, porque a URL do substituto não era uma parte canônica assinada do jeito que a gente gostaria.

O impacto depende do privilégio do daemon e do fluxo usado, mas o aviso menciona escalada remota para o usuário do daemon de build, corrupção remota da store, possível leitura local de arquivos acessíveis ao daemon e sobrescrita de cache com cara de negação de serviço. A leitura prática é atenção proporcional: a falha encosta numa parte sensível da cadeia de builds.

O caminho recomendado é atualizar guix e guix-daemon, reiniciar o daemon ou reconfigurar o sistema e ficar em commit 897832f374dcdc9eeaf19d01e70b9a92fccfc68c ou posterior. A opção --no-substitutes entra como decisão de ameaça: pode reduzir dependência de substitutos enquanto atualiza, mas troca isso por custo, tempo e build local. CVEs ainda estavam pendentes na fonte; então ficam pendentes aqui também.

Mesmo para quem nunca rodou Guix, o aviso bate em CI, cache de build, package manager e artefato assinado. A ordem das operações importa. “Vou verificar já já” é uma frase perigosa quando o dado já encostou no disco, no cache ou no daemon.

Fonte: GNU Guix.

Estudo com agentes mostra que pensar mais venceu ferramenta extra

Um paper no arXiv fez 90 execuções independentes de agente construindo o mesmo app: um quadro de retrospectiva em tempo real. A pergunta era simples de medir e difícil de responder no chute: o que melhora a primeira tentativa, mais raciocínio ou mais ferramenta?

No estudo, subir o esforço de raciocínio de High para xHigh levou as execuções perfeitas na primeira tentativa de 28% para 89%. Os prompts corretivos caíram cerca de cinco vezes. O custo subiu, mas numa faixa menor: de 9% a 29%.

Já a ferramenta de teste baseada em navegador aumentou o custo de 42% a 68% e não melhorou o score funcional nem a confiabilidade naquele experimento. Antes de colocar mais uma ferramenta no loop, vale descobrir se a falha vem de planejamento fraco, entendimento ruim da especificação ou decisão quebrada. Se vier daí, a ferramenta nova pode só deixar a conta mais cara.

O paper ainda registra que deploy em container falhou na primeira tentativa em 44% das execuções. E um prompt de design melhorou a qualidade visual de 3,0 para 4,5, sem ganho funcional. Para quem usa Codex, Claude Code, OpenCode ou qualquer loop parecido, isso é útil: meça a falha que você realmente tem antes de comprar a solução da semana.

O limite fica no tamanho do recorte. São 90 runs, uma aplicação, uma especificação e uma rubrica de 14 critérios com máximo de 42 pontos. Dá para aproveitar como sinal, não como lei universal. Pelo menos ajuda a derrubar a suposição automática de que “mais ferramenta” sempre compra confiabilidade.

Fonte: arXiv.

ClickHouse entra na briga dos logs com menos coluna lida e mais disciplina

Mat Duggan publicou uma defesa do ClickHouse para observabilidade, principalmente logs em volume alto. O argumento mais interessante passa pelo formato de armazenamento, não pela moda do banco da semana.

Logs são dados enormes, quase sempre acrescentados no fim, com consulta imprevisível depois. Num banco colunar, uma consulta que usa 3 campos de 40 não precisa ler os outros 37 do mesmo jeito. O autor dá um exemplo ilustrativo de 800 GB contra 40 GB lidos numa consulta desse tipo. Também atribui ao ClickHouse compressão de 10 a 14 vezes em dados de observabilidade, contra 2 a 3 vezes no Elasticsearch.

Os números de custo chamam atenção, mas precisam ficar bem atribuídos. Para 10 TB por dia, a estimativa do texto coloca Elasticsearch em US$ 95 mil a US$ 140 mil por mês mais licença, LGTM em US$ 55 mil a US$ 85 mil com mais de 180 pods e 3 a 5 engenheiros, Datadog podendo passar de US$ 1 milhão por mês, e ClickHouse em US$ 18 mil a US$ 28 mil. São números do autor, com premissas do autor, não benchmark independente.

O preço cobrado pelo ClickHouse vem em outro lugar: desenho de schema, escolha de ORDER BY, reequilíbrio manual depois de adicionar shards e ausência de PromQL nativo. Para time pequeno, isso pode ser ótimo. Para time sem paciência de modelar logs e rollups, vira outra fonte de incidente.

O texto funciona melhor como mapa de tradeoff. Se sua observabilidade está virando imposto mensal e a consulta costuma tocar poucas colunas, ClickHouse merece teste. Se a sua equipe depende de PromQL por tudo e não quer pensar em ordenação, compressão, partição e retenção, a economia do papel pode evaporar no plantão.

Fonte: Mat Duggan.

Grab migrou contadores de fraude com shadow reads e Rust no caminho

A Grab publicou um daqueles relatos de migração que parecem simples depois que alguém fez o trabalho difícil. O Counter Service, usado em fraude e controle de abuso, lida com dezenas de milhares de QPS e cerca de um bilhão de requisições por dia. Trocar a base por baixo disso sem downtime exige mais que mudar a connection string e observar.

A equipe colocou uma fachada de storage em Rust. Usou enum dispatch, em vez de trait object com alocação no heap a cada query, e criou modos de execução por configuração: Single, WithShadow e WithSplit. Com isso, dava para comparar resultado, escrever em paralelo e mover tráfego sem trocar o avião em voo segurando fita isolante.

Outro acerto foi admitir que a forma dos dados importava tanto quanto a base. O modelo antigo guardava baldes em muitas linhas. O novo usa registros com mapa, incluindo KEY_ORDERED_MAP, MapIncrementOp e MapRemoveByKeyRangeOp no Aerospike. Para contador, operação atômica e poda por faixa de chave são mais que detalhe elegante.

A migração teve rampas de sombra de 5%, 20%, 50% e 100%, com paridade acompanhada por métricas. A equipe também cita problemas reais, como maturidade de cliente, DNS e um experimento de índice primário em NVMe que trouxe picos de p99 e foi revertido para memória.

Os resultados, no workload da Grab, são fortes: p99 de leitura cerca de 50% melhor, disco perto de 1 TB em vez de 3 TB, custo por nó 45% a 50% menor e fator de replicação reduzido de 3 para 2. O cuidado é resistir ao atalho “use Aerospike”. Dá para reaproveitar o desenho: fachada, modo de sombra, rollback por config, métrica de paridade e modelo de dados que combina com a operação.

Fonte: Grab Tech.

Destaques rápidos

• Safari Technology Preview 247 ganhou um servidor MCP local para dev web. O WebKit apresentou o Safari MCP server via safaridriver --mcp, com ferramentas para DOM, rede, console, screenshots, avaliação de JavaScript e interação na página. O servidor roda localmente e, segundo a Apple, não faz chamadas de rede próprias; os dados capturados ainda vão para o agente ou modelo que você configurou. Fonte: WebKit.

• Manticore acelerou embeddings locais trocando o caminho ONNX. A equipe relata no Manticore Search 27.1.5 uma média de 14 vezes mais performance, saindo de 5 a 11 documentos por segundo para 70 a 230 no novo caminho com ONNX Runtime. O relato é útil pelo motivo: desligar intra_op_spinning, parar de agrupar textos de tamanhos muito diferentes e usar uma sessão compartilhada com chamadas concorrentes venceu a intuição de batching para esse workload. Fonte: Manticore Search.

• Credencial de agente pede proxy, não token real largado no workspace. Matthew Garrett propõe um desenho em que o agente recebe um token substituto, e um broker/proxy troca isso pela credencial real no momento da chamada. A ideia conversa com mTLS, SPIFFE e JWT, mas ainda é proposta de arquitetura, não padrão pronto. O ganho é simples: se o workspace vaza, o material roubado é menos reutilizável. Fonte: Matthew Garrett.

• NetScaler teve nova urgência depois da divulgação técnica. Na quarta-feira, Citrix apareceu aqui como pacote de correção. Agora o delta é que SecurityWeek e Lupovis relatam exploração ou sondagem específica de CVE-2026-8451 pouco depois da divulgação pública. A Citrix confirma que a falha afeta NetScaler ADC e NetScaler Gateway configurados como SAML IdP, com memory overread e CVSS 8.8. Para quem opera isso: aplicar versões corrigidas do CTX696604, checar a precondição SAML IdP e monitorar sem sair espalhando payload cru por aí. Fontes: SecurityWeek, Citrix, watchTowr e Lupovis.

Acompanhamento de tendências

Ontem, skills de agente apareceram por aqui como dependências que pedem manifesto, origem e lockfile. Hoje a conversa anda um passo: mesmo com arquivo revisado, a parte perigosa pode aparecer em tempo de execução, no histórico de PRs ou numa instrução de DevOps vaga demais para o agente adivinhar com segurança.

O paper sobre SkillCloak descreve skills maliciosas com ofuscação estrutural e empacotamento autoextraível. No resumo, o empacotamento SFS passou por todos os scanners testados em mais de 90% dos casos, enquanto o SkillDetonate reporta 97% de detecção com 2% de falso positivo. É pesquisa, não produto pronto, mas muda a pergunta: scanner estático sozinho começa a parecer pouco para coisa que executa com privilégio do agente.

Outro trabalho olha ataques distribuídos em código persistente, espalhados por histórico de PRs. Um monitor isolado não se mostrou robusto contra estratégias graduais e não graduais. A combinação de rastreador stateful de ligações com ensemble de monitores reduziu evasão gradual de 93% para 47% no monitor padrão mais fraco. Ainda é muita passagem. Revisar diff por diff não enxerga tudo quando o ataque depende da história.

O UnderSpecBench fecha o pacote pelo lado operacional. Ele mede 69 famílias de tarefas DevOps, 2.208 variantes de prompt e configurações com Claude Code, Codex e OpenCode. O resumo diz que instruções subespecificadas levaram agentes a violar pelo menos uma fronteira em 55,8% a 67,8% das execuções. Traduzindo para o plantão: “arruma o deploy” pode ser pedido pequeno para humano experiente, mas é um convite para agente escolher alvo, escopo e risco por conta própria.

O conjunto aponta para controles bem terrenos: sandbox para skill, auditoria de comportamento em runtime, revisão que acompanha histórico, fronteira explícita de ação, credencial mediada por proxy e instrução de produção com alvo e limite. A resposta prática é tirar agente do mundo encantado do prompt e colocar no mesmo mundo chato onde a gente já colocou pacote, CI, token e deploy.

Fontes da tendência: SkillCloak/SkillDetonate, Persistent-State AI Control, UnderSpecBench e Matthew Garrett.

Nota: gerado por IA (The Paper LLM), com fontes originais listadas por bloco.