Patterson revela ataque de IA ao RubyGems e exige revisão de código

Patterson披露AI对RubyGems的攻击并呼吁进行代码审查 与遵循“as-if”（仿效）规则的编译器不同，人工智能无法保证软件行为保真度，迫使程序员必须对其生成的所有内容进行审计。 Aaron Patterson围绕“as-if”规则构建了他的技术论点，表明只要可观察的行为对用户保持完全一致，编译器和运行时就可以在底层彻底改变代码。他实际探讨了Ractor如何带来并行性以及挑战记忆化（memoization）的新观察者、Ruby 4.0如何通过消除Class#new的栈帧将分配速度提升多达70%，以及ZJIT中的抽象解释如何大幅减少堆上创建的对象。在出人意料的第二部分中，他讲述了一个真实案例：自主AI代理串联了RubyGems.org的缓存漏洞与RubyDoc.info的容器，发动了一次鲁布·戈德堡机械（Rube Goldberg）风格的攻击。他总结道，与形式上保证“as-if”规则的传统编译器不同，生成式AI工具无法提供语义保真度的契约保证，这要求开发人员必须继续仔细阅读并理解他们自己的代码。 在Ruby 4.0中，对象实例化时的内联省略了Class#new的调用栈帧，在无需启用JIT编译器的情况下即可将分配速度提升高达70%。 (26:10) Ruby 4.1将引入Ractor局部垃圾回收（Ractor-local GC），以减少全局并发瓶颈，不过诸如JSON中的字符串去重等内部机制仍需全局扫描。 (19:51) ZJIT编译器利用抽象解释和静态堆分析来消除运行时分配，在Rack基准测试中将对象创建从1,000个大幅减少至仅8个实例。 (37:06) 自主AI代理串联了Fastly CDN上的HTTP缓存漏洞以及RubyDoc.info中通过.yardopts文件进行的任意执行，从而窃取凭据并在正式漏洞通报的数月前于RubyGems.org上重新发布gem包。 (54:34) Aaron Patterson驳斥了AI将取代传统编译器的论调：尽管编译器受严格的“as-if”规则约束，但AI对其生成的代码并不提供行为等价性的契约保证。 (59:13)

Aaron Patterson sustenta que a engenharia de compiladores e runtimes de Ruby é governada pela regra do "como se" (as-if rule), que permite transformações agressivas de código desde que o comportamento observável permaneça idêntico para quem o inspeciona. Ao contrastar essa garantia formal com experimentos de concorrência, o compilador ZJIT e um incidente de segurança com agentes autônomos no RubyGems, Patterson defende que a supervisão humana continua indispensável porque modelos de inteligência artificial não possuem tal contrato de fidelidade. A regra "como se" e custos de observabilidade (12:21) A regra do "como se" formaliza que um compilador ou runtime tem permissão irrestrita para reordenar, simplificar ou eliminar instruções, contanto que o comportamento observável do software coincida com o especificado pelo código original. Patterson destaca que qualquer otimização possui dois lados: a transformação interna e o observador externo. O impacto prático dessas intervenções varia de acordo com o grau de tolerância dos observadores a pequenas variações estruturais. No Ruby 4.0, a máquina virtual especializa o call site de alocação de objetos embutindo a lógica de instanciação diretamente no código (inlining) caso Class#new não tenha sido sobrescrito. Essa mudança remove o quadro de Class#new do rastreamento de pilha (backtrace), gerando alocações 70% mais rápidas em relação ao Ruby 3.0. Trata-se de uma otimização de baixo risco: opera em detalhes semânticos secundários que a vasta maioria das aplicações não monitora rigidamente, viabilizando ganhos de velocidade sem quebras de execução. Concorrência com Ractors e GC local no Ruby 4.1 (13:58) O advento dos Ractors introduz paralelismo real e expõe códigos cotidianos a múltiplos observadores simultâneos. Padrões tradicionais como a memoização condicional (@result ||= ...), antes considerados seguros devido ao Global VM Lock, tornam-se vulneráveis a condições de corrida quando executados entre Ractors distintos, disparando exceções imediatas de isolamento para evitar corrupções invisíveis. Para sincronização segura de estado global, a orientação é recorrer a estruturas como variáveis transacionais (TVars) ou de bloqueio via biblioteca ractor-sharing. Essa mudança observacional reflete-se também no gerenciamento de memória. Para evitar contenção em torno do garbage collector global, o Ruby 4.1 implementa coletores de lixo locais para cada Ractor com heaps isolados. No entanto, o isolamento perfeito encontra limites em dependências implícitas: o parsing simultâneo de JSONs idênticos em Ractors paralelos compartilha silenciosamente strings idênticas alocadas no heap principal devido à desduplicação interna de chaves da linguagem, mantendo referências cruzadas que ainda exigem coletas globais periódicas. Otimizações agressivas e deotimização no ZJIT (32:16) Para efetuar transformações de alto risco sem violar as regras da linguagem, o compilador ZJIT apoia-se em dois níveis de representação intermediária — HIR (alto nível) e LIR (baixo nível) — combinados a mecanismos de deotimização. O compilador insere patch points no código de máquina, que funcionam como marcadores estruturais. Caso invariantes críticas do Ruby sejam violadas em tempo de execução — como a redefinição de métodos, invalidação de operadores primitivos (BOPs) ou alteração de constantes —, a instrução binária é sobrescrita por um desvio que restaura o estado da pilha e devolve a execução ao interpretador CRuby. O ZJIT também emprega interpretação abstrata, simulando a execução lógica do programa em tempo de compilação sem dispará-lo fisicamente. Ao compilar um manipulador Rack simplificado processando 1.000 requisições simuladas, o compilador rastreou o fluxo do array de resposta [status, headers, body]. Como as variáveis temporárias não escapavam do método, o ZJIT realizou substituição algébrica direta dos índices e eliminou completamente a alocação da estrutura, reduzindo a criação de lixo no benchmark de cerca de 1.000 alocações para apenas 8 objetos. Cadeia de ataque e exploração de cache no RubyGems (43:52) Patterson detalha a cadeia de exploração iniciada na campanha de "gem stuffer" em maio, em que bots publicavam pacotes no RubyGems.org para acionar webhooks automáticos do serviço RubyDoc.info. Ao descompactar a gem, o mecanismo de documentação YARD lia um arquivo .yardopts oculto e executava scripts arbitrários dentro de contêineres Docker com saída irrestrita à internet. O script extraía dados, empacotava uma nova gem e reiniciava o ciclo de publicações. Conforme contas eram suspensas, agentes autônomos de IA da OpenAI identificaram e exploraram uma vulnerabilidade desconhecida (0-day) na camada de CDN Fastly do RubyGems.org. O cache armazenava respostas HTTP GET de autenticação básica durante uma hora quando enviadas com gzip pelo cliente Net::HTTP, permitindo a extração de chaves de API válidas de outros mantenedores. A análise cronológica confirmou que os bots automatizados abusaram do vazamento de cache entre um e dois meses antes de o problema ser formally reportado e corrigido pelos mantenedores. Patterson conclui rebatendo o argumento de que a inteligência artificial seria meramente o 'próximo compilador' dispensado de leitura humana: enquanto compiladores tradicionais oferecem a garantia matemática irrevogável da regra 'como se', prompts em linguagem natural não possuem contrato formal de equivalência semântica. Manter a supervisão e o hábito de auditar o código produzido continua sendo uma salvaguarda obrigatória na engenharia de software.

[2:13] Aaron Patterson: Quantos de vocês gostam de receber granadas de lama? [2:13] Aaron Patterson: Essa piada é minha. Agora você não pode contar isso no palco. É minha. Vou contar eu mesmo [3:27] Aaron Patterson: eu sou a Sparkle, e ele é o Motion, o que significa que eu subo no palco com gestos teatrais enquanto ele faz o trabalho de verdade [9:22] Aaron Patterson: A finalidade de um sistema é o que ele faz para aqueles que o observam. [23:17] ActiveSupport codebase: Como esse método é usado em muitos lugares e frequentemente envolve grandes partes do código do usuário, ele tem um objetivo de design adicional de minimizar seu impacto na pilha de chamadas visível. Uma exceção gerada dentro de um callback 'before' ou 'after' pode causar todo o ruído que quiser, mas quando o controle é passado suavemente para o bloco de chamada fornecido, queremos o mínimo possível de indícios de que estivemos aqui. [37:06] Aaron Patterson: Se você quiser trabalhar com IA, venha trabalhar no ZJIT, por favor. Adoraríamos contar com a sua ajuda [37:06] Aaron Patterson: Você se importa? Eu, particularmente, não. Acho ótimo que estejamos reduzindo isso. [54:34] Aaron Patterson: Para mim, foi uma loucura. Eu não conseguia acreditar. Todas essas peças se encaixam assim... como diabos isso pode estar acontecendo? [59:13] Aaron Patterson: Eu não precisei tomar nenhum remédio para ser otimista. Na verdade, sou um homem de meia-idade e não quero tomar mais nenhum remédio... tenho muitos deles [59:13] Aaron Patterson: Não acho que ser otimista em relação à IA ou ao nosso futuro signifique necessariamente que eu precise me render a ela. [59:13] Aaron Patterson: Vou continuar lendo meu código, e espero que vocês também o façam. [59:13] Aaron Patterson: Entra aí, perdedor, vamos programar

[0:09] Olá a todos. Olá. [0:11] Olá. Sim. [0:12] Antes de começarmos, gostaria de fazer um breve anúncio. [0:20] Comecei a desenvolver minha própria distribuição do Linux. [0:26] Eu queria mostrar a vocês como ele é inicializado, mas não pude colocar o [0:30] computador no palco, então o devolvi com a equipe de audiovisual. [0:35] Por isso, vou pedir para eles darem início à minha apresentação agora, por favor. [0:40] Ok. Tudo bem. [0:41] Ok. Eles vão ligar o computador. [0:47] Tudo bem. [0:48] Quando você pode abrir o PowerPoint para mim quando… [0:52] Ah, meu Deus. [1:00] A propósito, eu codifiquei isso com base na vibração. [1:07] Tudo bem. Ok. [1:08] Então, vamos Acho que é melhor começarmos. [1:11] Vou chamá-lo de AaronXP. [1:13] É o nome desse software. [1:15] A instalação leva 100 milissegundos. [1:17] E é muito importante para mim reduzir o tempo de instalação, [1:21] porque faço isso o tempo todo. [1:23] Acordo de manhã e instalo meu sistema operacional. [1:33] Tomar um café, instalar meu sistema operacional, atualizar o Chrome, [1:36] reinstalar o sistema operacional. Quer dizer, qual é! [1:44] Acho engraçado Acho irônico fazer uma piada sobre a crise financeira e, [1:50] em seguida, incentivar todo mundo a criar um monte de código em [1:56] Rust sem nem mesmo lê-lo. [1:59] Vou começar a vender seguros contra dívida técnica, então venham me procurar depois, [2:06] se quiserem comprar algum. [2:13] Eu sei, eu sei que todo mundo aqui adora usar IA. [2:16] Eu também. Adoro usar IA. [2:18] Adoro usá-la para fazer granadas de lama. É ótimo. [2:23] Muito bom. [2:24] Mas eu quero fazer quero fazer uma enquete com o público aqui. [2:28] Acho que, sim, vou fazer uma enquete. Ok. [2:30] Quantos de vocês gostam de receber granadas de lama? [2:35] Alguém pode levantar a mão? Ok, temos 2, 3. [2:37] Ah, algumas pessoas dedicadas aqui na frente. [2:40] Ótimo, obrigado. É bom ver isso. [2:43] Eu também recebi alguns Muito obrigado, Amanda, pelo seu trabalho árduo aqui. [2:47] Podemos dar uma salva de palmas para ela? Sim. [2:56] Então, quando ela estava exibindo os registros na durante essa conferência, [3:02] alguém tirou uma foto minha aqui na plateia. [3:06] Esse sou eu. [3:16] Tive que contar isso pra ela depois. [3:18] E aí pensei: “Agora você não pode Essa piada é minha. [3:21] Agora você não pode contar isso no palco. É minha. [3:24] Vou contar eu mesmo.” [3:26] Tudo bem. [3:27] Antes de fazer mais piadas hoje, quero fazer quero fazer [3:31] algo um pouco mais sério. [3:32] Vou chamar alguém aqui da plateia, uma pessoa específica, [3:36] e vou deixá-la na vergonha. [3:38] E ele está bem ali. [3:40] Mike D'Alessio. [3:41] Então, não sei se vocês viram a palestra dele, mas o Mike postou isso. [3:46] Nós nos conhecemos há mais de 20 anos. [3:49] Ele me enviou um pull request de código aberto para o Mechanize, [3:53] uma biblioteca em Ruby da época. [3:56] E, desde então, venho trabalhando com ele na comunidade de código aberto. [4:01] Cheguei até a trabalhar com ele na Shopify por um tempo. [4:05] Na verdade, ele era meu chefe lá. [4:09] Começamos juntos, criamos uma organização no GitHub chamada Sparkle Motion. [4:14] Eu sou a Sparkle, e ele é o Motion nessa parceria. [4:17] O que isso significa é que eu subo no palco com gestos teatrais, enquanto ele, [4:23] na verdade, faz o trabalho de verdade. [4:25] Hum, trabalhamos juntos, colaboramos em muitos, muitos projetos de código aberto. [4:31] Por exemplo, o Nokogiri, talvez você conheça. [4:34] Já vi isso em vários slides sobre, hum, instalações lentas de gems. [4:41] Hum, também trabalhamos com a gem SQLite3, e ele é muito, muito ativo na [4:48] equipe de segurança do Rails. [4:51] Mas o anúncio que quero fazer aqui hoje é que ele também é o mais novo membro [4:59] da equipe principal do Rails. [5:02] Então Obrigado. [5:04] Obrigado, Mike. [5:06] Agradeço muito, muito, muito mesmo pelo seu trabalho. [5:09] Não sei se o site já foi atualizado ou não, mas, de qualquer forma, obrigado. [5:13] Estou ansioso por isso — muito obrigado mesmo. [5:16] E nós… [5:16] fico feliz que você continue ativo, apoiando a gente. [5:23] Sim, sim. [5:24] Tudo bem, é emocionante estar aqui no, hum, Rails World. [5:28] E sei que muita gente já fez essa piada antes, mas eu também estou usando [5:33] o Claude para gerar meus slides. [5:36] Então, é ótimo estar aqui no AI World, no Texas. [5:40] Hum, foi legal aprender como podemos usar a IA — todos nós —, [5:44] todos podemos usar a IA para nos tornarmos programadores 1.000x melhores. [5:50] Então, todos nós aqui presentes hoje podemos usar a IA para nos tornarmos [5:54] programadores 1.000x. Ah, desculpem, esperem um pouco, [5:56] cometi um erro de digitação. [5:58] Quero dizer, 1.000 ex-programadores. [6:10] Tem alguém aqui que já andou nos táxis robóticos? [6:13] Para mim, isso é incrível. Sim, sim. [6:15] Se você ainda não andou neles, recomendo muito que experimente. [6:18] É muito, muito divertido. [6:20] Mas não se esqueça de levar um amigo com você, porque assim é muito mais divertido. [6:28] Sim. Tudo bem. [6:29] Feliz sexta-feira. Uhu! [6:31] Feliz sexta-feira a todos. [6:35] Em algum lugar do mundo, é sempre sexta-feira. [6:38] Meu nome é Aaron Patterson. [6:39] Também sou conhecido como Tenderlove. [6:41] Trabalho na equipe de infraestrutura do Ruby on Rails na Shopify e ajudo em [6:46] várias tarefas relacionadas à equipe. [6:48] Lá, eu me dedico a várias coisas. [6:50] É muito divertido. [6:51] Eu também tenho um gato. [6:53] Este é o meu gato. [6:54] Talvez vocês já o tenham visto aqui no em um dos balcões de check-in do Passport. [7:00] Hoje vou falar sobre desempenho, obviamente, porque é disso que [7:04] sempre falo nas apresentações. [7:07] Não sei mais sobre o que falar. [7:10] Vou falar sobre Ractors. [7:11] Vou falar sobre o ZJIT. [7:13] E, claro, vou falar sobre IA, já que estamos no AI World. [7:18] Então, é isso que vamos fazer. [7:21] E o motivo, o motivo pelo qual vou falar sobre essas coisas — o importante é que o [7:26] motivo é que, este ano, tenho trabalhado com desempenho, [7:30] com o Ractors, com o ZJIT e também com IA. [7:32] E sim, na verdade estou repetindo esses slides porque fico muito, [7:37] muito nervoso quando estou preparando apresentações, [7:40] com medo de não ter conteúdo suficiente para a conferência, [7:44] então acabo adicionando mais slides. [7:46] Mas sim, é sobre isso que vou falar hoje. [7:49] Este ano, este ano também escrevi um alocador de registros para o ZJIT, [7:54] e não vamos falar sobre isso hoje, mas queria incluir isso aqui porque esse [7:59] foi o projeto mais difícil em que já trabalhei. [8:02] E estou muito, muito orgulhoso do meu trabalho aqui. [8:05] E eu só queria, tipo, colocar isso aqui e dizer que fui eu quem fez isso. [8:09] E foi ótimo. [8:09] Então, estou orgulhosa de mim mesma por ter feito isso. [8:12] Ah, obrigada. [8:17] Também ganhei um novo gerente este ano. [8:20] E acho que as coisas estão indo muito bem com ele. [8:24] Não tenho certeza. [8:25] Gravei minha primeira reunião individual com ele e vou compartilhar a transcrição [8:31] com vocês hoje; espero que possam me ajudar a avaliar isso. [8:35] Então, na nossa, na nossa primeira reunião individual, ele me disse: “Aaron, [8:41] você só tem testado caminhos de código que geram erros”. [8:46] E eu disse: “Ah, bem, isso é porque estou esperando matrizes.” [8:57] É porque meu código é excepcional. [9:01] E ele não ficou muito satisfeito com isso, pelo que me parece. [9:05] Mas eu queria tranquilizá-lo, então disse a ele: “Não se preocupe, [9:09] essas reuniões só vão melhorar. [9:10] Eu vou garantir isso.” [9:14] Sim. Então, acho que as coisas estão indo bem. [9:17] Não tenho certeza. [9:19] Vou começar minha apresentação com uma citação. [9:22] O objetivo de um sistema é o que ele faz. [9:26] Já ouvi essa frase muitas vezes antes e, tipo, nunca parei para pensar [9:30] muito no que ela significava. Não sei. [9:32] Isso me faz pensar, e eu não gosto de fazer isso, então [9:36] não dei muita importância ao assunto. [9:38] Mas acho que falei sobre isso com meu gerente e pensei comigo mesmo: “Tudo bem, [9:43] quando estou tentando entender para que serve um sistema, preciso [9:47] entender o que ele faz”. [9:48] E como meu gerente era novo aqui, ele me perguntou: “Aaron, tipo, o que é isso? [9:53] Para que serve esse sistema em que você está trabalhando?” [9:58] E eu disse a ele: “Bem, é isso mesmo, o que o sistema faz?”. [10:01] E ele me mandou ir me foder. [10:03] Estou brincando. [10:04] Estou brincando mesmo. [10:06] Ele não diria isso pra mim. [10:08] Eu disse que o objetivo dele é gerar exceções. [10:13] Então, não tenho certeza. [10:14] Acho que essas conversas individuais estão indo bem. [10:16] Não sei. Não sei. [10:17] Vamos ver depois disso. [10:19] De qualquer forma, não gosto muito dessa frase, e o motivo é que [10:22] ela é muito ambígua. [10:23] Quando penso nisso, fico tipo: “tá, tudo bem”, mas logo em seguida me [10:27] pergunto: “o que esse sistema faz? O que ele faz?”. [10:30] Não sei. [10:31] Então, não sei qual é o objetivo, e por isso fico pensando: [10:34] “não sei qual é o objetivo”. [10:37] Não consigo entender isso. [10:38] E, pra te dar um exemplo, meu cérebro é pequeno demais pra isso. [10:43] Não consigo lidar com isso. [10:45] Pra te dar um exemplo, digamos que eu tenha viajado no [10:48] tempo com meu fiel Nokia 3310. Sim. [10:52] Tenho certeza de que há Alguém aqui tem esse celular? [10:54] Sim. Sim. [10:55] Claro que sim. [10:56] Tenho certeza de que há pessoas aqui que nunca viram isso antes, [10:59] mas esse é um celular indestrutível. É ótimo. [11:02] Digamos que eu viajasse no tempo com esse celular. [11:05] E se eu o desse a alguém que nunca tivesse visto um celular antes, essa pessoa [11:09] poderia até usá-lo como martelo. [11:14] Então fico pensando: será que o propósito desse celular é servir de martelo? [11:19] Tipo, se você interpretasse literalmente a frase que eu disse antes, [11:23] talvez respondesse que sim. [11:25] Quer dizer, eles claramente estão usando isso como martelo, então esse [11:29] é o propósito dessa coisa. [11:30] Mas, pra mim, seria um celular. [11:32] Acho que o sistema — o que o sistema faz depende de quem está [11:36] realmente olhando para ele. [11:37] Então, quando olho para aquele celular, vejo um celular e vou usá-lo como celular. [11:42] Mas se eu o levasse de volta no tempo, a pessoa que o visse ali o veria como [11:46] um martelo e o usaria como martelo. [11:48] Portanto, o que realmente importa é quem está observando aquele sistema. [11:53] Assim, se eu pudesse refinar a citação original, diria que a finalidade de um [11:57] sistema é o que ele faz para aqueles que o observam. [12:00] Alguém famoso disse isso no RailsWorld 2026. [12:03] Sim. [12:04] Então, tenho pensado muito sobre isso porque, como disse, [12:07] tenho trabalhado principalmente com otimizações de desempenho [12:11] ou otimizações de código. [12:13] E essa atitude específica de que estou falando, essa atitude observacional, [12:18] é amplamente conhecida entre os implementadores de linguagens. [12:22] E é conhecida como a regra “as-if”. [12:24] Existe uma regra chamada “regra do como se”, e você pode ler sobre ela na [12:29] Wikipédia, mas ela está, na verdade, codificada na linguagem de programação C++ [12:34] no que diz respeito à aplicação de otimizações ao código. [12:38] Então, vamos ler um trecho sobre a regra “as-if”. [12:41] A regra “as-if” diz que, em C++, é permitido aplicar qualquer transformação [12:45] de otimização a um programa durante a compilação, desde que tal otimização não [12:49] altere o comportamento observável do programa, conforme [12:52] especificado pela norma. [12:54] Em outras palavras, o compilador tem liberdade para fazer [12:57] quaisquer alterações que desejar no seu código, desde que o código seja executado [13:02] da maneira como você o escreveu, da maneira que parece que [13:05] deveria ser executado. [13:06] Agora, há algo um pouco estranho nessa frase específica, [13:09] nessa citação em particular. [13:11] Ela diz “conforme especificado pela norma”, algo que praticamente [13:15] não temos em Ruby. [13:16] Não existe, digamos, um padrão específico como o do C++. [13:20] Mas não vamos nos preocupar com isso por enquanto. [13:24] Então, hoje quero falar sobre otimizações sob a perspectiva do [13:29] comportamento observável. [13:33] Toda otimização tem dois lados: o que é afetado pela otimização e o que observa [13:38] essa otimização específica, seja quem for que esteja analisando esse código. [13:42] Agora, quanto ao primeiro, vamos examinar alguns exemplos desses [13:46] diferentes observadores e otimizações e ver como eles se influenciam mutuamente. [13:51] Então, o primeiro que vou mostrar a vocês — e garanto que praticamente todos já [13:56] fizeram isso antes, eu acho — é a memoização. [13:58] Esse é o primeiro, o primíssimo exemplo. [14:01] Tenho certeza de que todos nós já escrevemos esse padrão específico antes. [14:05] Temos uma função; sabemos que ela é cara, mas só precisamos calculá-la uma vez. [14:10] Então, calculamos uma vez e, em seguida, armazenamos o resultado em [14:14] uma variável de instância. [14:15] Tenho quase certeza de que muitas pessoas aqui já escreveram [14:19] código semelhante a esse. [14:20] Eu, pelo menos, já escrevi. [14:22] O único problema com isso — esse padrão de código específico — é que [14:26] incorporamos uma suposição ao código. [14:29] E a suposição é que esse código seja executado por apenas uma thread por vez. [14:34] Portanto, na verdade, existe uma condição de corrida nesse [14:38] código, na qual poderíamos acabar executando esse cálculo dispendioso várias [14:43] vezes, mas não percebemos isso porque temos o GVL no Ruby. [14:47] Bem, é mais ou menos aí que entram os Ractors. [14:50] Os Ractors nos permitem ter um verdadeiro processamento paralelo [14:55] em nosso código Ruby. [14:56] Isso significa que os observadores do nosso código mudaram. [15:01] Na verdade, podemos ter duas threads acessando exatamente esse [15:04] caminho de código ao mesmo tempo. [15:06] Isso significa que podemos ter vários observadores de um determinado [15:10] caminho de código em paralelo. [15:11] Felizmente, os Ractors lançam uma exceção para nós nesse caso. [15:14] Assim, em vez de ocorrer uma condição de corrida e causar algum problema no seu [15:19] aplicativo, você receberá uma exceção e terá a oportunidade de [15:22] corrigir o problema. [15:23] Espero que vocês tenham assistido à apresentação do Andrew. [15:26] Ele falou detalhadamente sobre esse tipo de coisa, mas vou repetir [15:30] um pouco disso aqui. [15:31] Mas, quando digo isso, não quero que você se assuste e pense: [15:35] “Bem, eu nunca deveria usar isso, nunca deveria usar esse padrão específico”. [15:40] Vou mostrar alguns exemplos desse padrão. [15:42] No primeiro caso, temos vários ractores acessando essa variável de [15:46] instância memorizada na classe Foo. [15:49] E o que isso significa é que temos uma condição de corrida na classe Foo, [15:53] e o bom é que o R1, esse ractor R1, vai de fato nos dar uma exceção [15:57] dizendo: “Ei, você não pode fazer isso”. [16:00] Você precisa fazer isso de maneira segura para threads. [16:03] Agora, o segundo caso… [16:04] na verdade, o segundo caso está correto. [16:07] Você pode ver que o padrão é o mesmo. Podemos usá-lo. [16:10] Está tudo muito, muito bem assim. [16:12] A questão é que, no segundo caso, temos apenas um observador desse [16:16] caminho de código específico. [16:17] Portanto, não há problema em usar esse padrão. [16:19] Só precisamos garantir que ele esteja isolado a um Ractor específico. [16:23] Agora, felizmente, assim como esse padrão de variáveis de instância no nível da [16:27] classe, vemos isso ser bastante comum em várias bases de código. [16:31] E, na verdade, haverá uma maneira de mitigarmos isso ou lidarmos com essa [16:35] situação na próxima versão do Rails. [16:38] E isso será feito com o módulo ActiveSupport/Ractors. [16:41] Com o módulo ActiveSupport/Ractors, existe um método `on_main` que nos permite [16:46] executar determinado código no ractor principal. [16:49] Portanto, se tivermos um cálculo demorado, precisamos que ele ocorra dentro do ractor [16:54] principal e armazenar algo em uma variável de instância no nível da classe. [16:58] Podemos fazer isso. [17:00] Agora, se você assistiu à apresentação do Andrew, sabe que isso causa [17:04] latência no seu aplicativo. [17:06] E a razão pela qual isso causa latência é que, se você transferir muitos — uma [17:10] grande quantidade de cálculos — para o Ractor principal, de repente esse Ractor [17:15] se torna o gargalo do seu aplicativo. [17:17] E você acabará observando um aumento na latência, pois todos estão [17:21] disputando esse Ractor. [17:22] Portanto, sempre que possível, recomendo fortemente o uso da gem “Ractor sharing”. [17:27] Ela foi escrita por Koichi Sasada, que é o autor principal do Ractor. [17:31] Então, espero que isso funcione muito bem como código baseado no Ractor. [17:34] Na verdade — não “espero”, mas sim “vai funcionar”. [17:37] Então, vocês deveriam usar isso. [17:38] Ele contém algumas — na verdade, muitas estruturas de dados [17:41] diferentes compatíveis com o Ractor. [17:43] Vou compartilhar algumas delas. [17:45] Vou compartilhar algumas delas aqui no Ractor. [17:47] Há duas aqui que gostaria de destacar, pois resolvem esse problema [17:51] específico que estávamos analisando. [17:53] A primeira são as variáveis de bloqueio (lock variables) e a segunda são as TVars; [17:58] a escolha depende da taxa de processamento que você deseja para sua aplicação. [18:02] Uma variável de bloqueio garante que um cálculo específico ocorra apenas uma vez, [18:06] enquanto a TVar permite que ele ocorra uma ou mais vezes — basicamente, [18:10] algumas vezes. [18:11] Portanto, a primeira é usada quando você tem um cálculo que não é idempotente e [18:15] precisa garantir que ele ocorra apenas uma vez; já a segunda é indicada quando o [18:20] cálculo é idempotente e, digamos, talvez isso seja aceitável. [18:23] Isso acontece algumas vezes. [18:25] Além disso, há muitas outras, muitas outras estruturas de dados ali. [18:29] E não quero assustar vocês a ponto de deixarem de usar essas estruturas de [18:33] dados, porque acho que a forma, a natureza da implementação dos Ractors, [18:37] significa que, mesmo se usarmos essas estruturas de dados, [18:41] não haverá nenhum impasse em nossas aplicações, nem problemas de segurança de [18:45] threads, pois, em vez disso, receberemos apenas exceções. [18:49] E a razão pela qual acho que não devemos ter muito medo dessas estruturas de dados [18:53] é que acredito que o alcance dos problemas seja bastante limitado. [18:57] Então, vamos dar um exemplo. [18:59] Aqui temos um servidor web simulado baseado em Ractor. [19:02] Então, ele simplesmente lê uma solicitação do soquete em um loop infinito e, [19:07] em seguida, atende à solicitação dentro de um Ractor. [19:10] E se pensarmos no ciclo de vida normal de solicitação-resposta desse processo, [19:14] estamos alocando a maioria dos nossos objetos dentro desse método `serve`. [19:18] Portanto, todas as nossas alocações ocorrerão lá dentro. [19:22] E, na verdade, a única vez que realmente precisamos nos preocupar com isso é [19:26] quando acessamos elementos externos. [19:30] Agora, é claro, a gente mexe em coisas externas, como constantes ou valores de [19:35] configuração, coisas desse tipo, mas acho que o número de pontos de [19:39] intervenção é bem menor do que a gente imagina. [19:42] Outro assunto sobre o qual quero falar um pouco é a observabilidade de dados [19:46] e como ela afeta o desempenho. [19:48] No Ruby 4.1, haverá — ele será lançado com um coletor de lixo local do Ractor. [19:53] Então, o que isso significa? [19:57] No GC, o coletor de lixo do Ruby é um singleton. [20:00] Então, sempre que um Ractor precisa alocar um objeto, ele vai pedir ao coletor [20:04] de lixo: “Ei, me dê um objeto”. [20:06] E se tivermos vários Ractors rodando em paralelo, bem, fica bem claro que [20:10] vamos enfrentar um gargalo aqui. [20:12] Então, vamos tentar alocar um monte de coisas, e aí todos esses Ractors [20:15] ficam esperando que o GC aloque tudo. [20:18] Por isso, no Ruby 4.1, teremos um coletor de lixo local para cada [20:21] Ractor, o que significa pilhas separadas para cada um, o que resolverá isso, [20:25] eliminando esse gargalo específico. [20:27] Assim, cada Ractor pode solicitar um objeto à pilha. [20:30] Agora, talvez também possamos aproveitar isso para obter uma coleta [20:35] de lixo mais eficiente. [20:36] Por exemplo, neste nosso servidor web simulado, podemos criar um [20:40] novo Ractor a cada solicitação. [20:42] E, quando a solicitação for concluída, podemos simplesmente liberar a [20:46] pilha e continuar o processo. [20:48] Portanto, teoricamente, podemos obter coletas de lixo mais eficientes com isso. [20:53] Bem, eu gostaria que a história acabasse por aí, mas ela é um pouco mais complicada [20:58] do que isso, e quero mostrar a vocês um exemplo do porquê. [21:01] Digamos que tenhamos esse exemplo de produtor-consumidor em Ruby. [21:05] Peço desculpas. [21:05] Peço desculpas por fazer vocês lerem código. [21:12] O produtor aloca um objeto em seu próprio heap dessa forma e, em seguida, [21:16] passa esse objeto para um consumidor. [21:18] Assim, quando isso acontece, tanto o consumidor quanto o produtor estão [21:22] apontando exatamente para o mesmo objeto, e você pode ver isso [21:26] pelo ID do objeto aqui. [21:27] Os dois reatores são capazes de observar o mesmo — exatamente o mesmo [21:31] objeto ao mesmo tempo. [21:33] Portanto, o que isso significa é que, quando um desses reatores é encerrado, [21:37] isso não significa necessariamente que possamos descartar o heap, pois pode haver [21:42] outros reatores apontando para esse heap. [21:44] Portanto, precisamos de alguma maneira de resolver essa situação. [21:48] A maneira como resolvemos isso é por meio de um coletor de lixo global, [21:52] um GC global, e você pode pensar nisso como uma coleta “major”, só que, [21:56] idealmente, ocorre com menos frequência do que uma coleta “major”. [22:00] Então, quero mostrar mais um exemplo. [22:02] No exemplo anterior, passamos propositalmente um objeto de um [22:06] reator para outro, e ambos conseguiram ver esse objeto. [22:09] Quero mostrar um exemplo diferente, no qual fazemos isso implicitamente. [22:13] Mostrei esse exemplo no Rails World no ano passado, mas acho que este [22:17] é um é um ótimo exemplo. [22:19] Temos duas análises de JSON. [22:21] Estamos analisando dois documentos JSON e, em seguida, examinando a chave no [22:26] documento JSON; e você verá aqui que essas chaves correspondem [22:29] exatamente ao mesmo objeto. [22:31] Elas têm o mesmo ID de objeto. [22:33] Podemos observar que se trata do mesmo objeto. [22:36] Agora, se pegarmos esse código e o dividirmos em vários ractors, [22:40] veremos que a string “hello” tem o mesmo ID de objeto em ambos os ractors. [22:46] Portanto, em ambos os ractors, essas chaves são desduplicadas entre os [22:49] ractors, e ambos os ractors veem a mesma string “hello”. [22:52] E o que está acontecendo nos bastidores é que estamos alocando uma string “hello” em [22:57] um heap — nosso heap principal do Ractor — e, então, os outros dois ractors [23:01] estão apontando para esse heap. [23:02] O que é interessante nesse exemplo é que isso possivelmente significa que estamos [23:07] afetando o desempenho do GC, mas não sabemos disso. [23:09] Isso está acontecendo implicitamente. [23:14] Então, quero dar um passo atrás por um minuto. [23:17] Temos analisado, temos analisado assuntos um pouco mais a fundo aqui. [23:21] Começamos analisando as otimizações que os desenvolvedores fazem. [23:25] Assim, vimos como os Ractors adicionam um novo observador ao sistema e os [23:29] impactos a jusante dessa adição. [23:31] Agora, quero analisar as otimizações da estrutura e da linguagem e, [23:35] especificamente, quero examinar as inconsistências no backtrace. [23:40] Então, aqui temos um exemplo de um callback de salvamento. [23:44] Estamos usando os callbacks do ActiveSupport. [23:47] Estamos criando uma espécie de ActiveRecord simulado aqui, [23:50] onde você pode misturar isso e, em seguida, chamar o método `save`, [23:54] obtendo assim um callback de salvamento. [23:57] E esse código de exemplo exibe a pilha de chamadas de dentro do nosso [24:01] callback de salvamento. [24:02] Se imaginarmos o rastreamento da pilha a partir disso, [24:06] podemos imaginar que veremos, primeiro, o bloco para os callbacks de execução e, [24:11] em seguida, o quadro do método `save`. [24:13] E como estamos executando isso apenas a partir de um script, veremos [24:17] `main` como o nível superior. [24:19] Então, vamos pegar esse módulo e incorporá-lo a uma classe, [24:23] uma classe sem callbacks. [24:24] Esse é, de certa forma, nosso caso base aqui. [24:27] Se executarmos isso, veremos, de fato, que sim, ele tem apenas 3, 3 frames de pilha. [24:32] Então, vamos tentar de novo, mas desta vez com 1 callback. [24:35] Nesse caso, vamos definir um callback, vamos definir um before_callback [24:39] e analisar o backtrace. [24:40] E vemos que, mais uma vez, há apenas, há apenas 3 frames aqui. [24:43] Então, isso é ótimo, e é o que esperávamos. [24:45] Agora, vamos fazer mais um. [24:46] Vamos definir um callback “around”. [24:48] Se fizermos isso, veremos que nosso rastreamento [24:51] de pilha, de repente, disparou. [24:52] Agora, lembre-se: não alteramos nada do código que estava dentro desse método [24:56] `save`, e, de repente, nosso rastreamento de pilha está completamente diferente. [25:00] Bem, enquanto eu investigava isso, achei muito engraçado encontrar [25:03] este comentário no ActiveSupport. Vou ler. [25:05] Diz o seguinte: “Como esse método é usado em muitos lugares e frequentemente envolve [25:10] grandes partes do código do usuário, ele tem um objetivo de design adicional de [25:14] minimizar seu impacto na pilha de chamadas visível.” [25:16] Uma exceção gerada dentro de um callback “before” ou “after” pode causar todo o [25:20] ruído que quiser, mas quando o controle é passado suavemente para o bloco de chamada [25:25] fornecido, queremos o mínimo possível de indícios de que estivemos aqui. [25:28] E essa é exatamente a regra do “como se” de que falávamos anteriormente. [25:32] Então, nesse caso, estávamos vendo mais pilha do que o [25:35] esperado, e isso estava acontecendo dentro do Rails. [25:37] E eu posso, eu posso perdoar isso porque temos, digamos, um código de aplicação [25:41] que está realizando mais tarefas. [25:43] Tipo, nós adicionamos um callback “around”, então, de certa forma, [25:47] sabemos que, sim, tudo bem, ele está trabalhando mais, então é claro [25:50] que haverá mais rastreamento de pilha. [25:53] Mas será que é possível obter menos traços de pilha do que o esperado? [25:57] Tipo, já vimos esse caso? Sim, já vimos. [25:59] Mas, antes de mais nada, sim, eu gosto mesmo de passar meus fins [26:02] de semana contando quadros de pilha. [26:04] Mas não acho que isso me torne um perdedor. [26:10] Então, aqui temos um exemplo de falta de um novo quadro de pilha. [26:14] Vou mostrar o que é isso. [26:15] Nesse código, temos o método 1, que chama o método 2 e, em seguida, [26:20] chama o 3, que aloca `foo`. [26:21] O `foo` chama o 4 de dentro do método `initialize`. [26:24] E o motivo pelo qual estou fazendo isso é apenas para deixar o rastreamento [26:29] da pilha um pouco mais claro. [26:32] Então, se executarmos esse código, esperamos ver um rastreamento [26:36] de pilha como este. [26:38] Veremos: initialize, new 3, 2, 1, main. [26:40] Nada de surpreendente. [26:42] Se executarmos o código no Ruby 3.4, é isso que vemos. [26:46] Esse é, exatamente, o rastreamento de pilha que vemos no Ruby 3.4. [26:51] Se executarmos isso no Ruby 4.0, veremos que fica um pouco diferente. [26:56] E, de fato, no Ruby 4.0, essa classe `New frame` não existe mais. [27:01] Ela sumiu. [27:02] Então, o que aconteceu com esse quadro da pilha? [27:06] Acho que podemos encontrar algumas pistas. [27:10] Vamos descobrir isso aqui. [27:12] Se analisarmos as instruções do método 3, acho que vamos conseguir [27:16] aprender alguma coisa. [27:17] Então, vamos analisar as instruções da VM desse método específico. [27:21] Na parte de cima, temos as sequências de instruções do Ruby 3.4. E na parte de [27:26] baixo, temos as sequências de instruções do Ruby 4.0. [27:30] E a primeira coisa que podemos perceber a partir disso é que o Ruby 4.0 gera muito [27:35] mais instruções do que o Ruby 3.4. Não vou explicar essas instruções em detalhes, [27:39] mas a mudança básica é que incorporamos a chamada à `initialize` [27:43] no novo local de chamada. [27:48] Exatamente aí. Fizemos uma implementação inline. [27:51] Então, se pegarmos essas instruções e as reescrevermos como código Ruby, [27:55] à esquerda aqui está o código que escrevemos, e à direita está, digamos, [28:00] o pseudocódigo das instruções que geramos. [28:03] O pseudocódigo das instruções basicamente diz: “ei, se o novo método em Foo for a [28:08] implementação padrão, então o que vamos fazer é alocar um novo [28:12] Foo, chamar diretamente o método initialize e, em seguida, [28:16] retornar o objeto. [28:17] Se não for o novo padrão, então vamos seguir um caminho mais lento [28:22] e simplesmente chamar o novo método”. [28:26] Portanto, faz sentido que haja mais instruções aqui, [28:29] pois ele está simplesmente fazendo mais do que o Ruby 3.4 fazia. [28:33] Outro ponto a ser observado aqui é que, na verdade, estamos chamando o método [28:37] `initialize` a partir do método `3`. [28:40] Antes, o modelo era o seguinte: chamávamos `new`, e `new` chamava `initialize`. [28:44] Agora, podemos ver aqui que `3` está chamando `initialize` diretamente. [28:48] Portanto, faz sentido que esse quadro de pilha do `new` esteja faltando. [28:54] Então, digamos que tenhamos esse código. É a nossa classe Foo. [28:57] Imprimimos o rastreamento da pilha do método `initialize` antes [28:59] de implementar o `new`. [29:00] Então, basicamente, vamos aplicar um “monkey patch” no `new`. [29:03] Mas não é um “monkey patch” nada complicado. [29:05] Estamos apenas chamando o `super` de dentro dele. [29:07] Então, aqui vamos exibir o rastreamento da pilha antes do `3`. [29:10] Vamos adicionar `new` e, em seguida, chamar o método novamente e exibir o [29:14] rastreamento da pilha mais uma vez. [29:15] Se fizermos isso, à esquerda está nosso rastreamento de pilha do caminho rápido e, [29:19] à direita, o do caminho lento, e podemos ver que nossa chamada ao [29:23] método `new` da classe está de volta. [29:24] Então, por que nos demos todo esse trabalho? [29:27] Tipo, por que, por que fazer tudo isso? [29:29] A razão é que, com isso, conseguimos alocações mais rápidas. [29:33] Neste exemplo específico, a alocação é 70% mais rápida no Ruby 4.0 [29:37] do que no Ruby 3.0. E isso sem um compilador JIT. [29:40] Portanto, obtemos ganhos de desempenho realmente bons com essa [29:44] otimização específica. [29:47] Então, o que a gente removeu nesse caso foi um quadro de chamada, [29:51] e os observadores disso seriam, por exemplo, o chamador, [29:54] depuradores e outros elementos que poderiam inspecionar a pilha. [29:57] Esses são, portanto, os elementos que foram afetados. [30:00] O que a gente ganhou com isso, porém, foi um aumento de 70% na velocidade das [30:04] alocações, o que eu acho que é uma boa troca. [30:06] E o CRuby faz isso o tempo todo. [30:08] Há muitos pontos diferentes em que ele faz isso. [30:11] Vou dar outro exemplo aqui bem rapidinho. [30:13] Aqui temos uma classe Foo de exemplo que implementa o método `hash`. [30:16] Ela exibe o rastreamento da pilha sempre que algo chama o método `hash` nela. [30:20] Acionamos um cálculo de hash e exibimos o rastreamento da pilha. [30:23] Portanto, esperaríamos que essas duas primeiras chamadas tivessem o mesmo [30:27] rastreamento da pilha, e que a última tivesse um rastreamento [30:30] diferente, mas com a mesma profundidade. [30:34] E, se observarmos, as pilhas são completamente diferentes. [30:37] Aqui, na verdade, estamos omitindo; conseguimos omitir o [30:40] método `square, square` no lado mais à esquerda. [30:43] Então, você verá que esse quadro está faltando, enquanto os outros [30:46] dois lados mostram tudo. [30:48] O CRuby faz isso o tempo todo. [30:49] Ele lida de forma bastante flexível com o rastreamento da pilha. [30:55] Mas acho que a questão é: tipo, quem se importa? [30:57] Sério, alguém se importa com isso? Não. [30:59] Alguém? Ah, algumas pessoas. [31:01] Tudo bem. Eu sei que acho isso interessante. [31:04] Mas, na verdade, é exatamente isso que quero que você sinta. [31:12] Se vocês realmente se importassem se essas coisas estavam ou não no quadro da pilha, [31:17] não seríamos capazes de implementar esse tipo de recurso. [31:20] É por isso que fico muito, muito feliz que a maioria de vocês [31:24] pense: “Bem, não me importo com isso”. [31:29] Acho que esse tipo de coisa é como se fossem áreas cinzentas, [31:31] áreas cinzentas nas regras. [31:33] Então, o compilador fez uma alteração no código, de modo que a execução, [31:36] estritamente falando, não é a mesma. [31:38] Dá para perceber uma diferença, mas esses são casos em que as [31:41] pessoas simplesmente não se importam. [31:42] Tipo, elas realmente não se importam, então tudo bem. [31:47] E no Ruby — e acho que na maioria das outras linguagens — precisamos manter o [31:51] comportamento onde ele realmente importa. [31:52] Então, esses casos, na verdade, não importam. [31:54] Estamos obtendo otimizações de desempenho, mas abrindo mão de coisas [31:57] que não importam de verdade. [32:00] Então, essas — acho que esses tipos de otimizações são o que gosto de chamar de [32:04] otimizações de baixo risco, nas quais alteramos o comportamento da [32:07] linguagem, mas as pessoas, em geral, realmente não se importam. [32:10] Elas apresentam baixo risco. [32:11] Então, a seguir, quero examinar algumas otimizações de alto risco, [32:14] especificamente dentro do ZJIT. [32:16] O ZJIT é capaz de realizar otimizações de alto risco porque consegue reverter a [32:19] otimização caso algo inesperado aconteça. [32:21] Então, vamos vamos dar uma olhada em algumas delas. [32:24] O ZJIT possui, internamente, dois tipos de representação intermediária. [32:26] Vamos analisar esses tipos. [32:30] A representação intermediária, também conhecida como IR, [32:33] possui um HR ou HIR de alto nível e um IR ou LIR de baixo nível. [32:37] Se você quiser testar isso em casa, pode visualizar o HIR adicionando [32:42] essas opções ao seu binário do Ruby. [32:44] Portanto, se você adicionar “ZJIT dump HIR”, poderá ver a saída [32:48] e dar uma olhada nela. [32:52] Uma das suposições que fazemos no ZJIT é que você provavelmente [32:55] não redefinirá métodos. [32:56] Provavelmente não fará isso. [32:57] Mas, se você fizer, precisamos saber, porque, nesse caso, [33:00] precisamos agir corretamente. [33:01] Então, digamos que tenhamos um exemplo como este, em que alocamos um ponto e, [33:05] em seguida, chamamos um método, que, por sua vez, chama um método nesse ponto. [33:11] Se gerarmos o HIR para isso, ele ficará assim, e vou destacar algumas [33:15] coisas aqui dentro, dentro desse HIR. [33:17] Primeiro, quero mostrar que temos um bloco aqui. [33:20] Então, podemos ver que este é o HIR de compilação do bloco, em 5 vezes. [33:25] A próxima coisa que quero destacar é que colocamos o `get` como inline no bloco, [33:30] mas inserimos um frame inline. [33:32] Portanto, estamos inserindo um frame inline para o `get`, de modo que ele [33:36] fica como inline dentro do bloco. [33:40] A próxima coisa que quero mostrar é que conseguimos, de fato, mover essa [33:44] constante 42 para dentro do bloco. [33:49] Assim, o ZJIT conseguiu pegar o código à esquerda e compilá-lo [33:52] para o código à direita. [33:54] Ele conseguiu simplificar tudo isso. [33:56] Mas como o ZJIT consegue fazer apostas tão ousadas? [33:59] Nós, talvez, não nos importemos se um quadro de pilha estiver faltando, [34:03] mas se o seu código redefinir `get` ou `x`, você provavelmente se importaria, [34:07] porque agora o seu código não está se comportando da maneira que você esperava. [34:12] Ele não está seguindo a regra “como se”. [34:15] Então, se voltarmos à saída do Hir, veremos algumas linhas de pontos de patch. [34:20] Vou destacá-las. Temos uma aqui. [34:22] Há um ponto de patch para a redefinição do método `get`. [34:25] E temos outro ponto de patch definido aqui para a redefinição do método `x`. [34:32] E esses pontos de correção não representam nenhum código. [34:35] Portanto, se você observar a saída do código de máquina, não há nada no código [34:38] de máquina que represente esses pontos de correção. [34:41] São simplesmente marcadores. [34:42] Esses marcadores — nós os usamos para saber em que parte do código de [34:45] máquina devemos aplicar a correção. [34:49] Então, digamos que tenhamos um código como o do nosso exemplo anterior. [34:53] Nesse caso, vamos compilar em JIT o bloco de 5 vezes. [34:56] Em seguida, vamos redefinir o método x e compilá-lo novamente em JIT. [35:00] Se fizermos isso, eis um trecho do código de máquina que o JIT gera, e vamos mostrar [35:05] como fica antes e depois da invalidação. [35:08] Então, esta é a versão antes da invalidação. [35:11] Portanto, quando o método `gets` é invalidado, o compilador JIT literalmente [35:16] sobrescreve o código de máquina. [35:18] Assim, ele pega esse código de teste. [35:20] Temos um marcador de invalidação que aponta para a instrução de teste e, [35:24] quando esse método for redefinido, simplesmente sobrescreveremos essa [35:28] instrução de teste com uma instrução de salto, e essa instrução de salto [35:33] irá para um código de saída. [35:35] Esse código de saída restaurará todos os componentes internos da VM e a pilha da [35:39] VM, e você continuará executando seu código na máquina virtual do Ruby. [35:44] Então, como detectamos esse caso? [35:46] Tipo, como sabemos que você redefiniu um método? [35:48] Fazemos isso com a ajuda do CRuby, a implementação do CRuby. [35:51] Sempre que um método é redefinido, precisamos invalidar os caches de qualquer [35:55] maneira, e esse também é o momento perfeito para o compilador JIT [35:59] invalidar qualquer código JIT. [36:00] Assim, o compilador JIT pode simplesmente rastrear quais métodos ele compilou e, [36:04] se alguém redefinir um método, ele poderá invalidar qualquer código [36:08] de máquina associado a esse método. [36:10] Então, aqui vamos dizer: “Ah, um método foi redefinido”. [36:13] Vamos invalidar todo o nosso código JIT para o YJIT ou o ZJIT, [36:16] dependendo de qual você estiver usando. [36:18] Portanto, a redefinição de métodos não é a única invariante que monitoramos. [36:21] Também monitoramos itens como as chamadas de operações básicas, ou BOPs. [36:25] Por exemplo, no caso do método “plus”, precisamos garantir que “plus” [36:28] continue significando “soma”. [36:30] Monitoramos constantes, portanto, precisamos garantir que você não as [36:33] redefina, ou que haja pontos de rastreamento; pois, [36:36] se você executar um ponto de rastreamento, isso significa que poderá observar [36:40] elementos que o compilador JIT possa ter otimizado e removido, [36:43] e precisamos corrigir isso. [36:45] Isso não segue a regra do “como se”. [36:46] E há várias outras também; se você quiser saber mais sobre as outras, por favor, [36:50] venha conversar comigo depois. [36:54] E, como eu disse, eu falaria sobre IA porque estamos no AI World. [36:58] E o ZJIT utiliza bastante IA. [37:00] Nós a usamos bastante. [37:01] E, infelizmente, sei que isso vai decepcionar algumas [37:04] pessoas, mas estou me referindo à interpretação abstrata. [37:11] Uhu! [37:11] Então, se você quiser trabalhar com IA, venha trabalhar no ZJIT, por favor. [37:16] Adoraríamos contar com a sua ajuda. [37:18] O que é interpretação abstrata? [37:20] Interpretação abstrata é quando fingimos executar um código. [37:25] Vamos simular a execução do código e, a partir daí, permitir que as [37:28] otimizações surjam naturalmente. [37:29] Então, vou mostrar um exemplo para ajudar a explicar o que isso [37:32] significa exatamente. [37:33] Aqui à esquerda, temos um servidor de teste. [37:35] Trata-se apenas de um aplicativo Rack de teste. [37:38] À direita está o nosso servidor real — ou, desculpem, um servidor de teste. [37:41] À direita está nossa aplicação Rack. [37:43] E aqui embaixo, na parte inferior, temos apenas um método simples que mede o [37:48] lixo — mede o número de objetos que alocamos. [37:50] E ele tenta processar cerca de 1.000 solicitações falsas por [37:54] meio dessa aplicação Rack. [37:55] Se executarmos isso com um compilador JIT, ou se executarmos sem um compilador JIT, [38:00] serão alocados cerca de 1.000 objetos. [38:02] Isso faz sentido, pois fizemos cerca de 1.000 solicitações. [38:06] Se executarmos com o YJIT, veremos que ele aloca aproximadamente [38:11] o mesmo número de objetos. [38:13] E, se executarmos com o ZJIT, veremos que ele aloca 8 objetos. [38:17] Então, de onde vêm esses objetos e como o ZJIT consegue removê-los? [38:22] Vamos voltar ao nosso programa de demonstração; fica bem claro a partir [38:27] dele de onde vêm essas alocações. [38:29] Estamos alocando uma matriz aqui no método `call`, com nossos cabeçalhos [38:34] de status e o corpo da mensagem. [38:37] Então, já vimos, já vimos no exemplo anterior que o [38:40] ZJIT pode fazer inline de funções. [38:42] O que está acontecendo aqui é que o ZJIT está pegando essa chamada ao método `call` [38:47] e fazendo inline dela dentro do método `serve`. [38:50] Então, digamos que a gente tenha feito isso. [38:52] Vamos incorporá-la aqui assim. [38:54] Agora, o que quero fazer aqui é, digamos, pegar esse código e dividi-lo [38:58] em partes mais simples. [39:00] Vamos dividir isso em várias etapas, usando variáveis temporárias, [39:04] e fazer uma parte de cada vez. [39:06] Então, vamos pegar a atribuição dos cabeçalhos de status e do [39:09] corpo da resposta e dividi-la. [39:11] Se fizéssemos isso, acabaríamos com algo assim, [39:14] em que atribuímos todas essas variáveis a variáveis intermediárias e, [39:18] em seguida, as usamos dessa maneira. [39:20] E acho que todos concordamos que o comportamento desse programa [39:23] é o mesmo do anterior. [39:25] A única diferença é que temos mais variáveis temporárias. [39:30] E é aí que entra a interpretação abstrata. [39:32] Nosso interpretador abstrato vai percorrer esse código e simular sua execução. [39:37] Então, vamos… vamos percorrer isso agora. [39:40] A primeira coisa que faremos é criar um heap abstrato. [39:43] E esse heap abstrato mantém um registro de como os objetos ficariam se [39:47] executássemos o programa. [39:49] E vamos simular essa execução. [39:51] Então, criamos um heap abstrato e, em seguida, armazenamos os valores nele. [39:55] Assim, vamos simular a execução. [39:57] Sabemos que, se executarmos a primeira linha, v1 receberá o valor 200. [40:01] v2 receberá o valor da constante “headers”. [40:04] v3 receberá o valor do corpo. [40:06] E então algo especial acontece com v4. [40:08] v4 será atribuído a um array abstrato. [40:11] Portanto, temos um array abstrato aqui. [40:14] Esse array abstrato contém três valores: v1, v2 e v3. [40:17] E não nos importamos com quais são os valores de v1, v2 e v3. [40:22] Não nos importamos nem um pouco com o que eles são. [40:24] Só sabemos que há esses valores dentro dele. [40:27] Depois disso, vamos atribuir “status” ao primeiro elemento da matriz. [40:30] Em seguida, vamos atribuir “headers” ao segundo elemento da matriz e, depois, [40:34] “body” ao terceiro elemento da matriz. [40:36] Agora, a próxima coisa que podemos fazer é dizer: “Bem, vamos fazer isso, [40:40] realizar uma substituição aqui”. [40:41] Sabemos que o status é atribuído ao valor v1. [40:44] Portanto, podemos simplesmente fazer uma substituição algébrica neste caso. [40:49] E vamos dizer: tudo bem, vamos apenas substituir esses valores. [40:53] E, se fizermos isso, há algo que percebemos nesse programa. [40:57] E é que v4 não é usado. [41:00] Não usamos a v4 de forma alguma. [41:01] Como não a usamos, isso significa que podemos eliminá-la. [41:04] Então, a eliminamos. [41:05] Depois, vamos ainda mais longe e dizemos: bem, sabe, também não precisamos dessas [41:09] variáveis intermediárias; então, vamos simplesmente movê-las para os [41:12] cabeçalhos de status no corpo do código e fazer atribuições diretas. [41:16] E podemos ser ainda mais ousados. [41:17] Podemos dizer: “Bem, vamos descer até aqui também”, então eliminaremos todas essas. [41:22] E podemos incorporar outras funções e executar o mesmo tipo de [41:26] algoritmo repetidamente. [41:27] E, dessa forma, usando a incorporação, a redução de constantes e a interpretação [41:32] abstrata, conseguimos converter o código da esquerda no código da direita, [41:36] e é assim que conseguimos — como conseguimos eliminar essas alocações. [41:41] Então, falamos sobre otimizações e os impactos que os observadores [41:44] têm nessas otimizações. [41:46] Falamos sobre paralelismo com os Ractors, eliminações de quadros de pilha no [41:50] interpretador, além de inlining e eliminação de alocações no compilador JIT. [41:55] Assim, conseguimos eliminar todas essas alocações neste compilador JIT. [41:59] E tenho uma pergunta para todos vocês aqui na plateia. [42:03] Essa otimização viola a regra “as-if”? [42:06] Conseguimos observar essa mudança contando o número de alocações no código. [42:10] Então, será que violamos a regra “as-if”? [42:15] Você se importa? [42:19] Eu, particularmente, não. [42:20] Acho ótimo que estejamos reduzindo isso. Tudo bem. [42:23] Eu ia encerrar a apresentação por aqui. [42:26] Então, ia dizer: obrigado. Conseguimos. [42:28] Retiramos algumas alocações. [42:30] Mas, na verdade, tenho outra história para contar. [42:32] Peço desculpas. Na verdade, são duas apresentações em uma. [42:35] Vamos passar para o segundo ponto aqui. [42:37] Ainda tenho 12 minutos. [42:39] Vamos tentar fazer isso. [42:41] Quero falar sobre algo que aconteceu muito, muito recentemente conosco na [42:46] comunidade e sobre a história que surgiu a partir disso. [42:50] Acho que é muito interessante. [42:52] Espero, espero que seja interessante para todos vocês. [42:55] Quero falar sobre o RubyGems e o incidente com a OpenAI. [42:58] Alguém já ouviu falar sobre isso? [43:00] Algumas pessoas, sim. Tudo bem. [43:03] Então, quanto à Espero que essa história seja interessante. [43:07] E para aqueles que ainda não ouviram essa história, espero que ela [43:11] continue sendo interessante. Em maio… [43:14] Quero recontar essa história basicamente da minha perspectiva. [43:18] Nos dias… 11 e 12 de maio, aconteceu algo. [43:21] O RubyGems. [43:21] org começou a receber milhares de gems indesejadas sendo enviadas. [43:29] Na verdade, quero voltar um pouco atrás. [43:32] Deixem-me voltar um pouco aqui. [43:33] Eu ia encerrar por aqui. Obrigado a todos. [43:35] Vamos dar uma salva de palmas para mim. Uhuuu! [43:40] Todos esses objetos foram eliminados. Ótimo. [43:45] Tudo bem. Vamos animar um pouco as coisas. [43:47] Então, nos dias 11 e 12 de maio, o RubyGems. [43:49] org começou a receber milhares de e-mails indesejados — ou, melhor dizendo, [43:52] “gems” indesejadas — enviadas. [43:53] Uma quantidade enorme delas. [43:55] Mais tarde, isso viria a ser chamado de campanha “gem stuffer”, mas na época ainda [43:58] não havia um nome específico para isso. [44:00] Quer dizer, quando você tá mandando um monte de coisas pro ar, [44:03] não dá pra perder tempo pensando num nome. [44:09] Em 12 de maio, Moshe Mansfield divulgou o ataque no Twitter. [44:13] Ele trabalha com o RubyGems. [44:14] org e verifica os novos pacotes que são enviados. [44:17] Estavam recebendo uma quantidade enorme de pacotes enviados. [44:20] Eles disseram: “Tudo bem, precisamos conter o problema. [44:24] Vamos desativar isso.” [44:25] Estamos enfrentando um grave ataque malicioso ao RubyGems. [44:28] org neste momento. Os cadastros estão suspensos. [44:30] Ele afirmou que estamos enfrentando um grave ataque malicioso ao RubyGems. [44:34] org e anunciou que os cadastros foram suspensos por enquanto. [44:39] No dia 13 de maio, o Socket. [44:41] dev publicou um post no blog chamando isso de “ataque gem stuffer”. [44:46] Na época, pensei: “Ok, isso é interessante”. [44:49] Li o post deles sobre o assunto. [44:52] O post está aqui, e você pode escanear o código QR aqui. [44:56] Eles chamaram isso de “gem stuffer”, “ataque gem stuffer” e [45:00] “campanha gem stuffer”. [45:02] Então, eu li o post do blog, e o post dizia mais ou menos assim: “Ok, [45:07] tem essas gems que estão sendo enviadas, e elas contêm um script malicioso; esse [45:12] script vai baixar algumas coisas do governo do Reino Unido” E aí… [45:17] Na verdade, talvez eu tenha algumas animações aqui. [45:20] Eu não tinha a menor intenção de falar sobre isso, e passei literalmente o [45:25] dia todo ontem trabalhando nos slides. Então, isso é… [45:29] ah, sim, ótimo. [45:30] Então, elas têm, elas têm essa gem maliciosa ou esse script malicioso dentro. [45:35] O script vai fazer solicitações ao governo do Reino Unido por algum motivo e, [45:41] em seguida, vai baixar todo o material do governo do Reino Unido. [45:45] Então ele faria o empacotamento — curiosamente, ele pegaria os dados que [45:50] baixou, os empacotaria em uma gem e, em seguida, enviaria essa gem [45:54] novamente para o RubyGems. org. [45:56] Na época, achei isso bem interessante, mas, se você ler o código — tipo, [46:00] aquele que eles mostraram na postagem do blog —, a primeira coisa que me veio à [46:05] cabeça foi: “Então, eles disseram: ‘Ok, você pode identificar que foi vítima disso [46:10] porque haverá esses arquivos no seu sistema de arquivos’. [46:14] Então, você pode encontrar esses arquivos no seu sistema de arquivos.” Eu dei uma [46:19] olhada nisso e, quando você instala uma gem normalmente — acho que todos sabemos [46:24] que, ao instalar uma extensão C, por exemplo, o extconf é executado —, [46:28] já temos ali um problema de execução remota de código. [46:32] Mas todo mundo sabe disso. [46:35] E quando dei uma olhada no exemplo deles, o script malicioso não [46:39] estava dentro de um extconf. [46:41] Eles não estavam usando uma extensão C para fazer isso. [46:44] Então pensei comigo mesmo: “Tudo bem, tanto faz. [46:47] Tipo, isso como isso está afetando alguém? Ninguém… [46:50] mesmo que você instale essa gem, ela não vai se executar sozinha.” [46:55] Tipo, você teria que acessar o gem e fazer isso especificamente. [46:58] Então, isso parece estranho. Como é que sim. [47:01] Como é que… [47:02] o artigo nunca aborda como o programa é executado e em que circunstâncias [47:06] ele seria executado. [47:07] Então, basicamente, eu só… [47:09] disse, tipo, tudo bem, tanto faz, estranho. [47:13] No dia 16 de maio, as inscrições reabriram e, para ser sincero, eu simplesmente [47:18] não pensei mais muito nisso. [47:19] No dia 6 de julho, Luke Marshall, da equipe de segurança da Truffle, [47:23] notificou a RubyGems — a equipe do RubyGems. [47:26] org — sobre um problema de segurança relacionado ao cache no RubyGems. [47:29] org. [47:30] E eu trabalho um pouco no cliente do RubyGems. [47:33] Então, eu faço parte da equipe do cliente RubyGems, mas não da equipe do servidor. [47:37] Mas é claro que a gente conversa, então a gente sabe, sabe como é, [47:41] a gente trabalha junto. [47:43] E o que é interessante sobre esse ataque é que Vou mostrar a vocês como ele funciona. [47:48] O que poderia acontecer é que a autorização antiga fosse feita [47:52] por meio de uma solicitação GET. [47:54] Então, isso é da perspectiva da vítima. [47:56] Você faria uma solicitação GET para autorizar gems. [47:59] Portanto, se você executasse o comando `gem auth`, ele executaria isso. [48:04] E o que aconteceria é que ele faria uma autorização básica, e então a resposta do [48:08] servidor seria assim, e você teria esse cache, essa chave lá embaixo. [48:12] Essa era a sua chave para fazer login. [48:14] E quero que você tenha esse formato de chave em mente aqui por um segundo. [48:19] Talvez um minuto, provavelmente mais do que um segundo. [48:22] Então era assim que ficava. [48:24] E, da perspectiva do invasor, a situação se apresentava assim. [48:28] O que estava acontecendo era que a Fastly estava posicionada na frente do RubyGems. [48:33] org e armazenando em cache as respostas GET do RubyGems. [48:37] org. [48:37] Assim, os invasores enviavam uma solicitação e, de repente, recebiam uma [48:42] chave armazenada em cache como resposta. [48:45] Portanto, os invasores não enviam o cabeçalho de autorização, [48:49] mas conseguiam obter um token de autorização válido em troca. [48:53] Isso não é nada bom. [48:55] Não está nada bom. [48:59] Ficou em produção por uns 6 anos. [49:03] É, é, não é nada empolgante, mas acho que pouca gente percebeu isso [49:07] porque, se você pensar bem, se analisar o comportamento disso, [49:10] em primeiro lugar, não havia indícios de abuso na época. [49:13] Ou seja, não havia indícios de que isso tivesse sido abusado, [49:17] pelo menos até onde se sabia na época. [49:19] É preciso definir `accept_encoding gzip` para que isso aconteça. [49:22] E isso isso é meio estranho, porque significava que quem usasse o [49:26] `curl` não perceberia, já que essa opção não vem ativada por padrão. [49:30] Então, isso simplesmente passou despercebido por muito tempo. [49:33] No entanto, o NetHTTP ativa isso por padrão. [49:36] E acho que isso também passou despercebido porque, tipo, se você se imaginar como um [49:41] mantenedor de gem, vai fazer, tipo, um `gem push`. [49:44] Então, você faria um “gem push” e, digamos, acabaria pegando [49:48] a chave de outra pessoa. [49:49] Tipo, você pegou a minha chave, mas vai enviar a sua própria gem. [49:53] Então, ao fazer o “gem push”, você receberia uma mensagem estranha [49:57] dizendo que não está autorizado a fazer o envio. [50:01] Porque você tá tentando usar seu próprio gem, mas tá tentando [50:03] usá-lo com a minha chave. [50:04] Então, simplesmente não funciona, e aí você fica tipo: “Ah, que estranho. [50:08] Login no gem”. [50:08] E, de repente, o problema se resolve e funciona, e você [50:11] simplesmente não liga, né? [50:12] Tipo, isso poderia ter acontecido. [50:15] Então, acho que foi por isso que o problema ficou sem ser [50:17] percebido por tanto tempo. [50:18] Além disso, só o Ruby — mais precisamente, o código antigo do RubyGems — usava isso, [50:22] e o cache expirava após 1 hora. [50:23] Então, três dias depois, eles lançaram uma correção para isso. [50:26] O problema foi totalmente resolvido. [50:27] Portanto, o RubyGems lançou uma correção. [50:31] No dia 8 de setembro, eu estava no trabalho. [50:36] Essa é a minha roupa de trabalho. [50:40] Recebi uma mensagem direta de uma das minhas colegas, a Emily, [50:43] e ela me disse: “Aaron, você vai receber um e-mail da Gemma”. [50:46] A Gemma é uma ex-colega de trabalho minha que está trabalhando na Anthropic. [50:51] E a Emily disse: “Você vai receber um e-mail da Gemma e vai ser sobre [50:55] um hack muito grave no RubyGems”. [50:57] E eu pensei: “Sabe, ela poderia simplesmente me mandar um [51:00] e-mail, não precisava me mandar uma mensagem direta”. [51:03] E aí a Emily disse: “Não, você é péssimo com e-mails”. [51:06] E eu fiquei tipo: “É, ah, certo, é verdade mesmo. [51:10] Tá bom.” Então recebo um e-mail. [51:12] Recebo um e-mail de Na verdade, isso… [51:14] Eu pulei uma parte da história aqui. [51:17] Então, a Gemma me mandou um e-mail e disse: “Aaron, vou te apresentar a essa [51:22] pessoa, o Neev, e rolou algum tipo de ataque muito grave ao RubyGems, e eles [51:27] querem conversar com alguém sobre isso.” [51:30] E eu fiquei tipo, “é, claro, tudo bem, quer dizer, posso conversar [51:33] com você sobre isso”. [51:34] E eu fiquei tipo e aí comecei a entrar em pânico porque percebi que não [51:36] sou bom em checar meus e-mails. [51:38] Então fiquei pensando: “Será que perdi algum e-mail? [51:40] Tem alguma coisa no HackerOne que eu não vi? [51:42] Tipo, o que eu fiz?” [51:43] Então, eu fico procurando freneticamente nos meus e-mails. [51:45] Ah, não. [51:45] Procurando por alguma coisa e não tem nada lá. [51:47] Aí eu respondo pra pessoa. [51:48] Eu digo: “Sinto muito, muito mesmo.” [51:50] Devo ter perdido seu e-mail ou algo assim, mas não consigo encontrá-lo [51:53] de jeito nenhum. [51:54] Essa pessoa me respondeu dizendo que não, que deve ter havido um engano. [51:58] Isso não é um problema atual do RubyGems. [52:00] Mas tem alguém, um pesquisador de segurança, tentando [52:02] entrar em contato com alguém do RubyGems. [52:05] E eu estou, tipo, usando meus contatos para entrar em contato com você. [52:08] E isso é, sei lá, interessante. [52:10] Então eu pensei: “Tudo bem, tá bom”. [52:13] Recebi um e-mail de uma pessoa chamada Sydney von Arx me dizendo que os agentes [52:18] da OpenAI tinham tentado explorar essa vulnerabilidade do RubyGems, a do cache. [52:23] Ela colocou o link. [52:27] E parece que esses quatro pacotes enviados tentaram explorar a vulnerabilidade para [52:34] roubar as chaves de API dos usuários. [52:37] E eu pensei: “Isso é uma grande besteira. Qual é! [52:41] Você não sabe disso.” Mas ela me mandou uns links. [52:45] E eu fico tipo: “Tá bom. [52:47] Bem, sabe, tô tentando ser uma pessoa responsável. [52:50] Vou clicar em todos esses links e ler tudo.” [52:58] Meludite lendo o código. [52:59] Enfim, então eu cliquei nos links e li o conteúdo. [53:02] E vou mostrar pra vocês: aqui está um trecho de uma das pérolas [53:05] que ela me enviou. [53:06] Não é o texto completo, mas fiquem à vontade para escanear o código QR ali. [53:09] Ele leva ao texto completo, então vocês podem dar uma olhada e ler, se quiserem. [53:15] E vou destacar algumas coisas aqui, neste código. [53:18] A primeira é o comentário no início que diz “leaked_keys variants”. [53:23] E eu começo, tipo, a suar na cadeira, e penso: “Nossa, isso não é nada bom”. [53:28] E dá pra ver que está dentro desse script chamado script. [53:32] rb. Além disso, o nome da gem é sln-leaker-5. [53:36] Estranho. É mesmo. [53:37] A seguir, percebi que ele está fazendo uma solicitação GET ao RubyGems. [53:42] org. [53:42] E eu não coloquei o não coloquei o caminho aqui, mas é o caminho de autorização. [53:47] É isso mesmo. [53:50] Então olhei para a parte de baixo e vi essa expressão regular específica, [53:55] que vocês talvez tenham reconhecido na resposta, a resposta da [53:59] chave de autenticação. [54:01] E percebi o que isso estava fazendo e pensei: “Nossa, sim. [54:05] Isso estava tentando invadir o RubyGems. org”. [54:08] Então respondi a eles e disse: “Ah, tudo bem, sim. [54:12] Isso é muito, muito interessante”. [54:16] E eles perguntaram se poderiam marcar uma reunião, tipo, uma reunião comigo. [54:19] E eu falei: “Claro, vamos nos encontrar e conversar sobre isso”. [54:23] Então, marcamos uma reunião. [54:24] É, ah, sim, esse sou eu. [54:25] Percebendo o que está acontecendo aqui. [54:29] Estou conversando com eles e digo: “Como ok, isso é muito interessante. [54:32] Vocês me enviaram isso. [54:34] Está, mais uma vez, no script. rb. [54:35] Como isso está sendo executado em algum lugar? [54:38] Tipo, como alguém executaria isso?” [54:40] Não está no extconf. [54:41] E ela me disse que estava sendo executado no rubydoc. [54:46] info. [54:50] E eu fiquei tipo: “O quê?”. RubyDoc. [54:52] info. Se você acessar o RubyDoc. [54:54] info, verá que é apenas um servidor de documentação. [54:58] Ele exibe a documentação de várias gems. Vamos ver. [55:01] O que é isso, afinal? [55:03] Se você der uma olhada dentro do gem, verá que há um arquivo yardopts. [55:07] O arquivo yardopts tem a seguinte aparência. [55:10] E você verá que ele aponta para diz algo como “load . [55:14] /script. rb”. [55:14] E o que acontece é que, se você tiver o gem yard instalado, [55:18] ele instala um plugin do RubyGems. [55:21] E então, se você instalar outra gem, ao instalá-la, a gem Yard irá procurar [55:27] dentro da sua gem por um arquivo YardOps. [55:30] E, se encontrar um arquivo YardOps, ela executará este código aqui. [55:35] Então, ela executará isso. [55:37] E ela me disse que sempre que uma gem fosse enviada, vamos ver se eu tenho sim. [55:43] Então, o que estava acontecendo aqui é que um bot enviava uma gem para o RubyGems. [55:49] org assim. [55:51] O RubyGems. [55:52] org enviaria então um webhook para o RubyDoc. [55:54] info. Portanto, o RubyDoc. [55:55] info não tem nenhuma relação — é completamente independente do RubyGems. [55:59] org. Ele enviaria um webhook para o RubyDoc. [56:02] info. O RubyDoc. [56:03] info diria: “Ótimo, há uma nova gem publicada”. [56:05] Em seguida, ele baixaria a gem. [56:08] Então, ele baixava o arquivo, o executava e o abria dentro [56:10] de um contêiner do Docker. [56:12] O contêiner do Docker ainda tinha acesso à rede. [56:14] Ele executava o script malicioso. [56:15] O script malicioso então baixava dados do governo do Reino Unido. [56:18] Em seguida, ele empacotava esses dados como uma gem. [56:22] Isso faria com que a gem fosse enviada para o RubyGems. [56:25] org. O RubyGems. [56:26] org enviaria um webhook para o RubyDoc. info. [56:29] O RubyDoc. info executaria scripts maliciosos. [56:32] Ele baixaria dados do governo do Reino Unido, etc., etc., etc. [56:36] Então, isso era uma loucura. [56:38] Para mim, foi uma loucura. Eu não conseguia acreditar. [56:44] Todas essas peças se encaixam assim. Isso é loucura. [56:47] Tipo, como, como diabos, como isso pode estar acontecendo? [56:50] Quero fazer, tipo, quero fazer uma espécie de revisão cronológica disso porque [56:55] isso me deixou de queixo caído. [56:57] Então, nos dias 11 e 12 de maio rolou a campanha do “gem stuffer”. [57:01] E quanto a esses RubyGems, dá para verificar as datas de envio. [57:04] São de 11 de maio. Então, tudo bem. [57:06] O relatório do cache do RubyGems chegou em 6 de julho, e a pessoa que o enviou [57:11] era totalmente independente da OpenAI. [57:13] Ela não tinha qualquer tipo de vínculo com a empresa. [57:16] Eles descobriram isso por conta própria. [57:19] Então, esses bots já sabiam desse problema há, sei lá, um mês, [57:23] ou dois meses, eu acho. [57:24] E tudo isso aconteceu bem antes da violação de segurança [57:28] da Hugging Face também. [57:30] Por fim, em 12 de setembro, Sydney e sua equipe publicaram o rubyhack. [57:34] ai, e eu recomendo que vocês leiam. [57:36] É uma análise muito boa e aprofundada sobre esse ataque específico. [57:42] Então, o que me deixou apavorado é que os bots descobriram que o RubyGems. [57:47] org envia um webhook para o RubyDoc. info. [57:50] Eles descobriram que o Yard executa código arbitrário no RubyDoc. [57:55] Bem, ele executa código arbitrário mesmo. [57:58] Depois, descobriram que — o rubydoc. [58:00] info processa o YardDoc com conexão de rede e executa esse código. [58:05] Também descobriram isso — pelo menos é o que eu suspeito. [58:09] Você vai perceber, se der uma olhada em todas as gems e na [58:12] campanha de “gem stuffing”, que nem todas têm esse código para baixar chaves. [58:17] E acho que isso se deve ao fato de que, quando essas gems começaram a ser [58:21] enviadas, o pessoal do RubyGems — a equipe do RubyGems. [58:25] org — começou a desativar as contas e a impedir que elas fizessem login. [58:29] E o bot pensou: “Nossa, preciso de uma maneira de fazer [58:32] login quando não tiver credenciais. [58:34] Então, vou usar essas credenciais.” E eles decidiram explorar uma [58:38] vulnerabilidade 0-day no RubyGems. org. [58:42] Isso é uma loucura pra mim. [58:43] Eles descobriram essa máquina do Rube Goldberg. [58:46] Agora, a equipe do RubyGems. [58:47] org — tem um final feliz. A equipe do RubyGems. [58:49] org conseguiu resolver a situação. [58:51] Tipo, eles resolveram tudo completamente, consertaram, arrumaram tudo, [58:54] taparam os vazamentos. [58:56] Pelo que sabemos, ninguém, absolutamente ninguém foi explorado. [59:02] Portanto, não houve nenhum dano às pessoas da comunidade. [59:07] Ele está bem. Sim. [59:08] Então, muito obrigado a todos eles. [59:13] Então, quero encerrar esse assunto por aqui. [59:15] Sou um otimista em relação à IA. [59:17] Uso a IA todos os dias para escrever código. [59:19] Uso o tempo todo. Na verdade, quero mudar isso. [59:22] Quero mudar um pouco isso. [59:24] Sou apenas um otimista, não necessariamente um [59:27] otimista em relação à IA. [59:28] Acho que este é o melhor momento para se estar vivo e acredito de verdade [59:33] que as coisas só vão melhorar. [59:35] Mas o fato é que, tipo, eu não precisei tomar nenhum remédio para ser otimista. [59:40] Na verdade, sou um homem de meia-idade e não quero tomar mais nenhum remédio. [59:45] Tipo, eu tenho Ah, não. [59:49] Tenho muitos deles, mas não acho que ser otimista em relação à [59:53] IA ou ao nosso futuro signifique necessariamente que eu [59:56] precise me render a ela. [59:58] Já ouvi, já ouvi o argumento de que a IA é apenas nosso próximo compilador. [60:02] Você não precisa ler o código de máquina que seu compilador produz, certo? [60:07] Então, por que você precisaria ler o código de máquina ou o [60:11] código que sua IA produz? [60:12] Isso faz Eu consigo entender esse argumento, de certa forma. [60:16] É verdade, você provavelmente não lê o código de máquina que seu compilador gera. [60:22] Mas isso ocorre porque o compilador fez uma promessa a você, fez essa [60:25] promessa a você: a regra “como se”. [60:27] Seja qual for a ação que ele execute, o comportamento que você pode observar [60:31] corresponde ao código que você escreveu. [60:33] E tudo o que mostrei a você nesta apresentação ilustra o custo [60:36] de manter essa promessa. [60:37] Agora, sua IA não fez essa promessa a você. [60:39] Não existe uma regra “como se” para o seu inglês. [60:44] Portanto, não vou entregar meu destino à IA. [60:47] Vou continuar lendo meu código, e espero que vocês também o façam. [61:01] E quero encerrar com este slide. [61:05] Entra aí, perdedor, vamos programar. [61:10] Obrigado.