- FFmpeg é um framework open source central para processamento de mídia no mundo todo e um componente essencial usado por grandes serviços como VLC, Chrome e YouTube
- Recentemente, o scanner de segurança baseado em IA do Google encontrou um bug menor relacionado a um codec de jogo de 1995, ampliando a controvérsia de que grandes empresas estariam impondo um peso excessivo a desenvolvedores voluntários
- O FFmpeg afirma que “o projeto é mantido quase inteiramente por voluntários” e que o Google não deveria apenas relatar vulnerabilidades, mas também fornecer patches ou apoio financeiro
- O Google destacou sua política pública do Project Zero e o programa Patch Rewards como exemplo de contribuição transparente para a segurança, mas a comunidade do FFmpeg criticou o limite de recompensas e a falta de apoio prático
- A discussão expõe o problema da geração em massa de CVEs por IA e da sustentabilidade da manutenção de open source, ampliando o debate sobre a responsabilidade das grandes empresas de tecnologia
Visão geral do conflito entre FFmpeg e Google
- O FFmpeg é um framework multimídia open source que oferece suporte a transcodificação, reprodução e streaming de arquivos de áudio e vídeo
- Bibliotecas centrais como libavcodec e libavformat são usadas em VLC, Kodi, Plex, Chrome, Firefox e YouTube
- Mas, como outros grandes projetos open source, enfrenta grave escassez de recursos financeiros
- No Twitter, surgiu uma discussão entre FFmpeg, Google, Chainguard e pesquisadores de segurança sobre como divulgar vulnerabilidades de segurança e quem deve assumir a responsabilidade
- O foco do debate foi que grandes volumes de relatórios de vulnerabilidades gerados por IA muitas vezes têm baixo valor prático
O estopim da polêmica: um bug menor encontrado pela IA do Google
- Um agente de IA do Google encontrou no FFmpeg um bug relacionado à decodificação do codec LucasArts Smush
- O problema é uma vulnerabilidade de severidade média que afeta apenas os primeiros 10 a 20 frames do jogo de 1995 Rebel Assault 2
- Os desenvolvedores do FFmpeg corrigiram o problema, mas criticaram o relatório ineficiente, chamando isso de “CVE slop”
- O FFmpeg afirmou “FFmpeg aims to play every video file ever made”, destacando que busca compatibilidade total, mas observou que grande parte do código foi escrita em linguagem assembly, o que dificulta a manutenção
O peso sobre os mantenedores de open source
- A comunidade do FFmpeg critica o fato de que grandes empresas como o Google, que usam o FFmpeg, estariam empurrando correções de vulnerabilidades para voluntários não remunerados
- Sua posição é que o Google deveria, ao relatar vulnerabilidades, também fornecer patches ou apoio financeiro
- Em caso semelhante, o mantenedor do libxml2, Nick Wellnhofer, anunciou que deixaria a manutenção por causa de repetidos relatórios de segurança de terceiros
- Ele afirmou que “é insustentável que um voluntário não remunerado passe várias horas por semana lidando com questões de segurança”
A polêmica sobre a política de divulgação do Google Project Zero
- Em julho de 2025, o Google Project Zero (GPZ) introduziu a política de ‘** Reporting Transparency**’
- Após a descoberta de uma vulnerabilidade, há divulgação em até 1 semana, e em seguida começa automaticamente um prazo de 90 dias para correção
- A divulgação ocorre mesmo sem patch pronto, o que gera críticas por impor pressão excessiva sobre projetos mantidos por voluntários
- O FFmpeg questionou: “É justo que a IA encontre problemas de segurança em código de hobby e exija que voluntários os corrijam?”
- Embora exista o Patch Rewards Program do Google, o FFmpeg apontou que “com limite de 3 casos por mês, isso não oferece ajuda prática de verdade”
Visões opostas e a sustentabilidade do open source
- Dan Lorenc, da Chainguard, defendeu o papel do Google, dizendo que a divulgação de vulnerabilidades também é uma contribuição para os bens públicos digitais
- Segundo ele, “o Google é uma das empresas mais ativas no apoio ao open source, e esse tipo de disputa pode até afastar patrocinadores”
- Ainda assim, o FFmpeg enfatiza que faltam pessoal e recursos para responder ao grande volume de CVEs gerados por IA
- Especialistas em segurança reconhecem que, como o FFmpeg é um componente central da infraestrutura da internet, a divulgação de vulnerabilidades é necessária
- No fim, o artigo ressalta que “sem apoio concreto das grandes empresas, é impossível manter projetos open source centrais” e cita o caso do libxml2 para reforçar a necessidade de uma estrutura de financiamento sustentável
15 comentários
Será que isso não vai acabar desandando, tipo a ruptura na relação entre a fundação WordPress e a empresa WP Engine?
Parece ser uma continuação de
https://daniel.haxx.se/blog/2024/…
Se no texto acima eram relatórios completamente errados enviados por indivíduos de olho em bug bounty, no caso do FFmpeg são relatórios válidos, porém triviais, enviados por uma grande empresa.
O FFmpeg é necessariamente obrigado a responder só porque o Google apontou isso?
Como a vulnerabilidade em si acaba sendo divulgada, parece que não há outra opção a não ser reagir.
Ahá... eu não tinha pensado por esse ângulo. Obrigado por avisar!
Então é uma parte que pode ser atacada depois que a vulnerabilidade é divulgada, né, credo
Na verdade, poderiam até dizer “será divulgado ou não, se isso te incomoda então conserte você mesmo~”, mas acho que o projeto chegou até aqui porque os mantenedores não têm esse tipo de postura.
Ahá... acho que o que você disse está certo.
Acho que pensei demais apenas do meu ponto de vista.
Obrigado pelo comentário!
Opiniões no Hacker News
Houve um trecho na matéria que me chamou atenção. A história de que, dentro da Amazon, Mark Atwood precisou explicar aos chefes que “eles não são um fornecedor, não há NDA, e não temos como exercer influência sobre eles” para barrar decisões relacionadas ao FFmpeg.
Eu concordo com a ideia de “não traga só problemas, traga soluções”, mas acho que, se a Google tem dinheiro para encontrar bugs, também pode gastar dinheiro para corrigi-los
Assim, não é preciso depender de patches privados, é uma forma de retribuir ao projeto que ajudou você primeiro, e também é o certo do ponto de vista ético.
Mas, na prática, o problema era que barreiras internas de compliance ou de processo dificultavam fazer upstream
Imaginei uma licença satírica em que, para um funcionário de empresa do S&P500 reportar um bug, seria preciso fazer uma doação de determinado valor, e, se não pagar acima de certo patamar, não poderia esperar resposta dentro de um prazo definido.
Quando lhes convém, as empresas não hesitam em manter software fechado ou mudar para AGPL, então agora está na hora de pagar diretamente
Como mantenedor de open source, entendo a sensação de que grandes empresas, ao divulgarem problemas de segurança, acabam impondo trabalho gratuito.
Mas, na prática, independentemente de quem reportou, questões de segurança no fim são algo que eu preciso resolver.
Tudo bem se o projeto não prioriza segurança, mas então ele também precisa aceitar o risco reputacional decorrente disso
Exigir correção rápida de empresas comerciais faz sentido, mas impor a mesma exigência a um OSS baseado em voluntariado não é realista
Dizem que o problema só acontece nos primeiros 10 a 20 frames de um jogo de 1995, então achei exagerado classificá-lo como “gravidade média”.
Parece um caso de desperdiçar o tempo do mantenedor
Se for um problema sério, é bom que qualquer pessoa avise; se for um relatório trivial ou errado, basta ignorar.
No fim, o próprio projeto deve decidir quais bugs corrigir
Apoio a posição da equipe do FFmpeg. Muitas empresas usam FOSS apenas como lavagem de imagem para marketing, e na prática não contribuem.
Pessoas que antigamente talvez simplesmente pirateassem agora usam graças à licença, sem peso na consciência
Testar até codecs que ela não usa internamente é um objetivo puramente de interesse público.
Claro que a Google poderia apoiar financeiramente mais o FFmpeg, mas não concordo em dar dinheiro diretamente a esse mantenedor nesta situação
Dá para usar livremente, mas também abre espaço para abuso.
Há críticas de que a GPL 3 vai longe demais, mas pelo menos havia a intenção de impedir exploração
Há pessoas criando software que define uma era de graça, e empresas que usam isso para extrair todo o valor.
Os primeiros se movem por amor; as segundas, por transação
Para grandes empresas, a divulgação pública de vulnerabilidades é necessária, mas, para OSS com poucos recursos, o risco pode ser maior
Se a Google quer correções rápidas, mandar o patch junto beneficia todo mundo
Especialmente se forem vulnerabilidades num nível que um LLM consegue encontrar, a chance de abuso algum dia é grande.
Graças à divulgação, os usuários podem se defender por conta própria, e o fato de o FFmpeg ter decidido corrigir isso foi uma escolha voluntária.
A própria pesquisa em segurança é uma forma de contribuição de alto custo para o open source.
Dizer ao pesquisador que “a contribuição não é suficiente” acaba, ao contrário, exigindo trabalho gratuito de voluntários
A transparência do FOSS ajuda, na verdade, na percepção de segurança
Não se reconhece a zona cinzenta da realidade
Se “um único e-mail pode parar três linhas de produto”, então um apoio anual de 10 a 20 mil dólares já pareceria plenamente justificável como seguro
Se Google e Amazon contribuíssem com apenas 50 mil dólares cada, os desenvolvedores do FFmpeg poderiam trabalhar com estabilidade,
e a Google, especialmente por operar o YouTube, poderia facilmente pagar algo como 100 a 200 mil dólares
Compartilho uma thread no Twitter em que o responsável de segurança da Google organizou o histórico de contribuições ao FFmpeg
Não convence dizer que uma empresa de 1 trilhão de dólares não tem gente ou dinheiro suficientes
Tenho curiosidade sobre o propósito do Project Zero.
Queria saber se há algo além de simplesmente encontrar vulnerabilidades
Ao mesmo tempo, também ajuda em atração de talentos de segurança e gestão de reputação.
Mas, se há folga para isso, também deveria haver investimento na escrita dos patches
A vulnerabilidade em questão era um Use After Free, e foi a IA da Google que a encontrou.
Mas corrigi-la seria coisa de menos de 3 segundos.
É desagradável ver uma empresa cheia de dinheiro despejando relatórios de bug com cara de spam em um projeto voluntário
Nem parecia algo no nível de ser classificado como CVE; um simples relatório de bug já bastaria
Para evitar vazamento de memória, seria necessária uma correção mais complexa.
Provavelmente, o caminho certo para esse codec é continuar desativado por padrão
Deram comida e agora estão pedindo a trouxa toda, né?
Relatórios de bug também certamente devem ser uma contribuição importante...
Parece mais ou menos como alguém que, por vontade própria, faz a limpeza do bairro, e o figurão que mais possui terrenos ali vira para essa pessoa e diz: "tem uma bituca de cigarro naquele canto ali".
Eu também acho que essa analogia faz sentido.
É uma analogia apropriada.
Será que isso é realmente algo para comemorar? Lendo com atenção, trata-se de uma vulnerabilidade de segurança de gravidade média que só é válida nos primeiros 10 a 20 frames de um jogo específico bem antigo. Você realmente acha que isso é uma contribuição importante para o FFmpeg? A contribuição mais importante para a comunidade open source seria oferecer apoio financeiro para que o desenvolvimento possa continuar de forma estável, especialmente no caso de empresas que estão usando muito bem esse resultado; parece que isso deveria vir primeiro, não?
Foi por causa de pessoas assim que colocaram um backdoor no XZ
O relatório de bug em si é de nível S, mas eles saem espalhando por todo lado que não foi possível corrigir dentro do prazo uma vulnerabilidade grave em um formato de vídeo da época do presidente Kennedy.
Não estão dando algo que dá para comer; estão dando algo que você é obrigado a comer e perguntando por que não conseguiu terminar dentro do prazo.
O FFmpeg tem mão de obra limitada, então será mesmo certo o Google despejar dezenas de relatórios de bugs, usando IA, sobre formatos que hoje nem são mais usados, e pressionar para que todos sejam corrigidos dentro do prazo?