- FFmpeg es un framework open source clave para el procesamiento de medios en todo el mundo, y un componente esencial usado por servicios como VLC, Chrome y YouTube
- Recientemente, el escáner de seguridad basado en IA de Google detectó un bug menor relacionado con un códec de juegos de 1995, lo que desató una controversia sobre cómo las grandes empresas imponen una carga excesiva a desarrolladores voluntarios
- Desde FFmpeg afirman que “el proyecto se mantiene casi por completo gracias a voluntarios” y sostienen que Google no debería limitarse a reportar vulnerabilidades, sino también aportar parches o apoyo financiero
- Google destacó su contribución transparente a la seguridad citando la política de divulgación de Project Zero y el programa Patch Rewards, pero la comunidad de FFmpeg cuestionó el límite de recompensas y la falta de apoyo práctico
- Esta disputa pone en evidencia el problema de los CVE generados masivamente por IA y la sostenibilidad del mantenimiento open source, y abre el debate sobre la responsabilidad de las grandes tecnológicas
Resumen del conflicto entre FFmpeg y Google
- FFmpeg es un framework multimedia open source que permite transcodificación, reproducción y streaming de archivos de audio y video
- Sus bibliotecas principales, como libavcodec y libavformat, se usan en VLC, Kodi, Plex, Chrome, Firefox y YouTube
- Pero, al igual que otros grandes proyectos open source, enfrenta una grave falta de financiamiento
- En Twitter surgió una discusión entre FFmpeg, Google, Chainguard e investigadores de seguridad sobre la forma de divulgar vulnerabilidades y quién carga con la responsabilidad
- El eje del debate fue que los reportes masivos de vulnerabilidades generados por IA muchas veces tienen poco valor real
El origen de la polémica: un bug menor encontrado por la IA de Google
- Un agente de IA de Google encontró en FFmpeg un bug relacionado con la decodificación del códec LucasArts Smush
- El problema solo afectaba los primeros 10 a 20 cuadros del juego de 1995 Rebel Assault 2 y fue clasificado como una vulnerabilidad de severidad media
- Los desarrolladores de FFmpeg lo corrigieron, pero criticaron este tipo de reportes ineficientes y los describieron como “CVE slop”
- FFmpeg recordó que su meta es “FFmpeg aims to play every video file ever made”, pero señaló que gran parte del código está escrito en lenguaje ensamblador, lo que dificulta su mantenimiento
La carga para quienes mantienen open source
- La comunidad de FFmpeg criticó que grandes empresas que usan FFmpeg, como Google, trasladen la corrección de vulnerabilidades a voluntarios no remunerados
- Su postura es que Google debería acompañar los reportes con parches o apoyo financiero
- Como caso similar, se citó a Nick Wellnhofer, mantenedor de libxml2, quien anunció que dejaría el mantenimiento debido al flujo constante de reportes de seguridad de terceros
- Según explicó, es insostenible que un voluntario sin pago dedique varias horas cada semana a gestionar problemas de seguridad
La controversia por la política de divulgación de Project Zero
- En julio de 2025, Google Project Zero (GPZ) introdujo la política de “Reporting Transparency”
- Tras descubrir una vulnerabilidad, esta se hace pública en una semana, y automáticamente comienza un plazo de 90 días para corregirla
- Se critica que la divulgación avance incluso si el parche aún no está listo, lo que impone una presión excesiva a proyectos sostenidos por voluntarios
- FFmpeg cuestionó si es justo que la IA encuentre problemas de seguridad en código hecho como hobby y luego exija a voluntarios corregirlos
- Aunque existe el programa Patch Rewards de Google, FFmpeg señaló que “con límites como tres casos por mes no ofrece una ayuda real”
Visiones contrapuestas y la sostenibilidad del open source
- Dan Lorenc, de Chainguard, defendió el papel de Google al afirmar que divulgar vulnerabilidades también es una contribución a los bienes públicos digitales
- Sostuvo que Google es una de las empresas que más activamente apoyan el open source, y que este tipo de discusiones podría incluso alejar a potenciales patrocinadores
- Pero desde FFmpeg remarcan que no cuentan con el personal ni los fondos necesarios para responder a grandes volúmenes de CVE generados por IA
- Especialistas en seguridad reconocen que, como FFmpeg es un componente clave de la infraestructura de internet, sí es necesario divulgar sus vulnerabilidades
- El artículo concluye que sin apoyo concreto de las grandes empresas es imposible sostener proyectos open source críticos, y usa el caso de libxml2 para subrayar la necesidad de un modelo de financiamiento sostenible
15 comentarios
¿No se romperá la relación, espero, como pasó entre la Fundación WordPress y la empresa WP Engine?
Parece estar en la misma línea de
https://daniel.haxx.se/blog/2024/…
Si el texto de arriba trataba de reportes completamente erróneos que individuos enviaban buscando una recompensa por bugs, el caso de FFmpeg son reportes válidos pero menores enviados por una gran empresa.
¿Google está obligado a responder necesariamente solo porque lo señala?
Como la vulnerabilidad misma termina haciéndose pública, parece que no les quedará otra opción que responder.
Ah, ya veo... No había considerado esa perspectiva. ¡Gracias por explicarlo!
Entonces se trata de la parte en la que, al hacerse pública la vulnerabilidad, podrían usarla para atacar, qué miedo.
La verdad, aunque podrían decir “si les preocupa, arréglenlo ustedes mismos”, parece que el hecho de que los maintainers no sean de ese tipo de personas es lo que ha permitido que esto avance hasta aquí.
Ah, ya veo... creo que tiene razón.
Parece que pensé demasiado desde mi propio punto de vista.
¡Gracias por decírmelo!
Opiniones de Hacker News
Hubo una parte del artículo que me llamó la atención. Contaban que dentro de Amazon, Mark Atwood tuvo que explicarles a sus jefes que “ellos no son un vendor, no hay NDA y no podemos ejercer influencia sobre ellos” para frenar decisiones relacionadas con FFmpeg.
Estoy de acuerdo con eso de “no traigas solo problemas, trae también soluciones”, pero si Google tiene dinero para encontrar bugs, también podría gastar dinero en arreglarlos
Así no dependes de parches privados, puedes retribuirle al proyecto que te ayudó en primer lugar y además es lo correcto desde el punto de vista ético.
Pero en la práctica, el problema era que hacer upstream era difícil por las barreras internas de compliance o de procesos en las empresas
Me imaginé una licencia satírica en la que, para reportar un bug, un empleado de una empresa del S&P500 tendría que donar cierta cantidad de dinero, y si no paga por encima de cierto monto, no puede esperar respuesta dentro de un plazo determinado.
Cuando a las empresas les incomoda algo, no dudan en ejecutar el software de forma privada o cambiarlo a AGPL, así que ya es hora de que paguen directamente
Como mantenedor de código abierto, entiendo esa sensación de que las grandes empresas te imponen trabajo gratis al hacer públicos problemas de seguridad.
Pero en la práctica, sin importar quién lo reporte, al final sigue siendo un problema de seguridad que me toca resolver a mí.
Está bien que un proyecto no ponga la seguridad como prioridad, pero entonces también tiene que asumir el riesgo reputacional que eso implica
Exigir correcciones rápidas a empresas comerciales tiene sentido, pero pedir lo mismo a un OSS basado en voluntariado no es realista
Dicen que solo ocurre en los primeros 10 a 20 frames de un juego de 1995, así que me parece excesivo clasificarlo como de “gravedad media”.
Parece un caso de hacer perder el tiempo a los mantenedores
Si es un problema grave, está bien que cualquiera lo avise; si es algo menor o un reporte erróneo, se puede ignorar.
Al final, el propio proyecto debe decidir qué bugs corregir
Yo apoyo la postura del equipo de FFmpeg. Muchas empresas solo usan el FOSS para lavado de imagen de marketing, y en realidad no contribuyen.
Gente que antes simplemente habría pirateado el software ahora lo usa sin culpa gracias a la licencia
Probar incluso códecs que no usan internamente tiene un propósito puramente de interés público.
Claro que Google podría financiar mucho más a FFmpeg, pero no estoy de acuerdo con darle dinero directamente a este mantenedor en particular
Se puede usar libremente, pero también deja espacio para abusos.
Se critica que la GPL 3 se pasa de estricta, pero al menos sí había una intención de impedir la explotación
Hay personas que crean software que define una era gratis, y empresas que lo usan para extraer todo el valor.
Los primeros se mueven por amor; las segundas, por transacción
Para las grandes empresas hace falta divulgación pública de vulnerabilidades, pero para el OSS con pocos recursos el riesgo puede ser mayor
Si Google quiere correcciones rápidas, que envíe también el parche y todos ganan
Sobre todo si son vulnerabilidades que un LLM puede encontrar, porque tarde o temprano podrían explotarse.
Gracias a la divulgación, los usuarios pueden defenderse por su cuenta, y que FFmpeg haya decidido corregirlo fue una elección voluntaria.
La investigación en seguridad en sí es una forma de contribución de alto costo al código abierto.
Decirle al investigador que “su aporte no es suficiente” termina pareciéndose más a exigir trabajo gratis a un voluntario
La transparencia del FOSS más bien ayuda a la conciencia de seguridad
No reconoce las zonas grises de la realidad
Si “un solo correo puede detener tres líneas de producto”, entonces un apoyo anual de unos 10 mil a 20 mil dólares sería más que suficiente incluso como seguro
Si Google y Amazon aportaran aunque fuera 50 mil dólares cada uno, los desarrolladores de FFmpeg podrían trabajar con estabilidad,
y Google, que además opera YouTube, fácilmente podría poner unos 100 mil o 200 mil dólares
Comparto un hilo de Twitter donde el responsable de seguridad de Google resume los aportes hechos a FFmpeg
Que una empresa de un billón de dólares diga que le faltan personas o dinero no resulta convincente
Tengo curiosidad por el propósito de Project Zero.
Quisiera saber si hay una razón más allá de simplemente encontrar vulnerabilidades
Al mismo tiempo, le conviene para atraer talento de seguridad y gestionar reputación.
Pero si tienen margen para eso, también deberían invertir en escribir parches
La vulnerabilidad en cuestión era un Use After Free, y la encontró la IA de Google.
Pero arreglarla sería cosa de menos de 3 segundos.
Es desagradable que una empresa llena de dinero le arroje reportes de bugs tipo spam a un proyecto llevado por voluntarios
Ni siquiera parece algo al nivel de una CVE; con un simple bug report habría bastado
Para evitar fugas de memoria hace falta una corrección más compleja.
Probablemente mantener ese códec desactivado por defecto sea el camino correcto
Les dieron de comer y ahora les exigen que entreguen hasta el costal.
Los reportes de bugs sin duda también deben ser una contribución importante...
Se siente más o menos como si alguien estuviera limpiando voluntariamente el barrio y el gran terrateniente, que es quien más tierra posee ahí, le dijera a la persona que está limpiando: "oye, hay una colilla de cigarro allá en esa esquina".
Yo también creo que esta analogía es acertada.
Es una analogía apropiada.
¿De verdad vale la pena? Si lo lees, es una vulnerabilidad de seguridad de gravedad media que solo aplica a los primeros 10~20 fotogramas de un juego clásico muy específico. ¿De verdad creen que esto es una contribución importante para FFmpeg? Creo que la contribución más importante para la comunidad de código abierto sería dar apoyo financiero para que pueda haber un desarrollo sostenible; especialmente si se trata de una empresa que está aprovechando bien ese resultado, eso debería ser la prioridad.
Por gente así fue que se metió una puerta trasera en XZ.
El reporte de bugs en sí es de nivel S, pero andan divulgando por todos lados que no pudieron responder dentro del plazo a una vulnerabilidad grave en un formato de video de la época del presidente Kennedy.
No te dan algo que puedas comer, sino algo que estás obligado a comerte, y luego te preguntan por qué no pudiste comértelo dentro del plazo.
FFmpeg tiene personal limitado; ¿es correcto que Google, usando IA, les lance decenas de reportes de bugs sobre formatos que ya ni se usan y los presione para que los arreglen todos dentro del plazo?