- FFmpeg est un framework open source essentiel au traitement des médias dans le monde entier, utilisé par des services majeurs comme VLC, Chrome et YouTube
- Récemment, le scanner de sécurité basé sur l’IA de Google a découvert un bug mineur lié à un codec de jeu datant de 1995, relançant la polémique sur la charge excessive que les grandes entreprises font peser sur des développeurs bénévoles
- FFmpeg affirme que le projet est maintenu presque entièrement par des bénévoles, et soutient que Google ne devrait pas se contenter de signaler des vulnérabilités, mais aussi fournir des correctifs ou un soutien financier
- Google a mis en avant sa politique de divulgation publique de Project Zero et son programme Patch Rewards pour souligner une contribution transparente à la sécurité, mais la communauté FFmpeg a pointé les limites des récompenses et le manque de soutien concret
- Cette controverse met en lumière le problème des CVE générées en masse par l’IA et de la pérennité de la maintenance open source, et relance le débat sur la responsabilité des grandes entreprises technologiques
Aperçu du conflit entre FFmpeg et Google
- FFmpeg est un framework multimédia open source qui prend en charge le transcodage, la lecture et le streaming de fichiers audio et vidéo
- Ses bibliothèques clés, comme libavcodec et libavformat, sont utilisées par VLC, Kodi, Plex, Chrome, Firefox, YouTube, etc.
- Mais, comme beaucoup d’autres grands projets open source, il souffre d’un grave manque de financement
- Sur Twitter, un débat a éclaté entre FFmpeg, Google, Chainguard et des chercheurs en sécurité autour de la manière de divulguer les vulnérabilités et de répartir les responsabilités
- Au cœur des discussions : le fait que les signalements massifs de vulnérabilités générés par l’IA ont souvent une valeur pratique limitée
L’origine de la polémique : un bug mineur découvert par l’IA de Google
- Un agent IA de Google a découvert dans FFmpeg un bug lié au décodage du codec LucasArts Smush
- Le problème n’affecte que les 10 à 20 premières images du jeu de 1995 Rebel Assault 2, et a été classé comme une vulnérabilité de gravité moyenne
- Les développeurs de FFmpeg l’ont corrigé, tout en dénonçant une « inflation de CVE (CVE slop) » et l’inefficacité de ce type de signalement
- FFmpeg rappelle viser une compatibilité totale avec la phrase « FFmpeg aims to play every video file ever made », mais souligne que la majeure partie du code est écrite en assembleur, ce qui complique la maintenance
Le fardeau des mainteneurs open source
- La communauté FFmpeg critique le fait que de grandes entreprises utilisatrices comme Google reportent la correction des vulnérabilités sur des bénévoles non rémunérés
- Elle estime que Google devrait accompagner ses signalements de vulnérabilités par des correctifs ou un soutien financier
- Exemple similaire : Nick Wellnhofer, mainteneur de libxml2, a annoncé l’arrêt de la maintenance en raison de signalements de sécurité répétés venant de tiers
- Il a expliqué qu’il n’était pas soutenable qu’un bénévole non rémunéré consacre chaque semaine plusieurs heures à traiter des problèmes de sécurité
La controverse autour de la politique de divulgation de Project Zero
- En juillet 2025, Google Project Zero (GPZ) a introduit la politique de « Reporting Transparency »
- Les vulnérabilités sont rendues publiques dans la semaine suivant leur découverte, puis un délai automatique de 90 jours pour les corriger commence
- La divulgation peut donc avoir lieu même sans correctif prêt, ce qui est critiqué comme une pression excessive sur les projets reposant sur des bénévoles
- FFmpeg pose la question : « Est-il équitable que l’IA trouve des problèmes de sécurité dans du code maintenu comme un hobby, puis exige que des bénévoles les corrigent ? »
- Bien que le programme Patch Rewards de Google existe, FFmpeg souligne qu’« avec une limite de 3 cas par mois, cela n’aide pas réellement »
Des points de vue opposés et la pérennité de l’open source
- Dan Lorenc de Chainguard défend le rôle de Google en affirmant que la divulgation de vulnérabilités est aussi une contribution au bien public numérique
- Selon lui, Google est l’une des entreprises les plus actives dans le soutien à l’open source, et ce type de controverse risque au contraire d’éloigner des sponsors
- De son côté, FFmpeg insiste sur le fait qu’il manque de personnel et de financement pour répondre au flot de CVE générées par l’IA
- Des experts en sécurité reconnaissent que la divulgation de vulnérabilités reste nécessaire, FFmpeg étant un composant essentiel de l’infrastructure d’Internet
- La fin de l’article souligne qu’il est impossible de maintenir des projets open source critiques sans soutien concret des grandes entreprises, en citant le cas de libxml2 pour insister sur la nécessité d’un modèle de financement durable
15 commentaires
Espérons que cela ne finira pas par une rupture comme celle entre la fondation WordPress et l’entreprise WP Engine ?
On dirait que cela s’inscrit dans la continuité de https://daniel.haxx.se/blog/2024/…
Dans le billet ci-dessus, il s’agissait de rapports totalement erronés envoyés par des particuliers cherchant à profiter du bug bounty ; dans le cas de FFmpeg, ce sont des rapports valides mais mineurs envoyés par une grande entreprise.
Google doit-il forcément réagir à chaque problème qu’il signale ?
Comme les vulnérabilités elles-mêmes finissent par être rendues publiques, j’ai l’impression qu’ils n’auront pas d’autre choix que de réagir.
Ah, je vois... Je n'avais pas envisagé les choses sous cet angle. Merci de me l'avoir signalé !
Donc la vulnérabilité a été rendue publique, et cela ouvre la porte à des attaques avec ça, je vois, je vois.
À vrai dire, qu’ils rendent cela public ou non, on pourrait aussi se contenter de dire : si ça te gêne, corrige-le toi-même~ Mais on dirait que si le projet a pu évoluer jusqu’ici, c’est parce que ses mainteneurs ne sont pas de ce genre-là.
Ah, d'accord.... Je pense que vous avez raison.
J'ai sans doute trop réfléchi uniquement de mon point de vue.
Merci pour votre remarque !
Avis sur Hacker News
Un passage de l’article m’a marqué. Il y est raconté que, chez Amazon, Mark Atwood a dû expliquer à ses supérieurs que « ce ne sont pas un fournisseur, il n’y a pas de NDA, et nous n’avons aucun moyen d’exercer une influence sur eux » afin de bloquer des décisions liées à FFmpeg.
Je suis d’accord avec l’idée qu’il ne faut pas seulement apporter des problèmes mais aussi des solutions, mais si Google a de quoi financer la recherche de bugs, alors il peut aussi financer leur correction.
Cela évite de dépendre de patchs privés, permet de rendre à un projet qui vous a aidé au départ, et c’est aussi la bonne chose à faire sur le plan éthique.
En pratique, le vrai problème est souvent que les barrières de conformité ou de procédure internes aux entreprises rendent l’upstream difficile.
J’ai imaginé une licence satirique selon laquelle tout employé d’une entreprise du S&P500 qui veut signaler un bug doit d’abord faire un don d’un certain montant, et qu’en dessous d’un seuil donné, il ne peut pas espérer de réponse dans un délai déterminé.
Quand cela les arrange, les entreprises n’hésitent pas à faire tourner le logiciel en privé ou à passer à l’AGPL ; il est donc temps qu’elles paient directement le prix.
En tant que mainteneur open source, je comprends le sentiment selon lequel les grandes entreprises donnent l’impression d’imposer du travail gratuit en rendant publics des problèmes de sécurité.
Mais dans les faits, quel que soit l’auteur du signalement, un problème de sécurité finit de toute façon par être quelque chose que je dois résoudre.
Un projet peut très bien choisir de ne pas faire de la sécurité sa priorité, mais il doit alors aussi accepter le risque de réputation qui en découle.
Exiger une correction rapide d’une entreprise commerciale se défend, mais appliquer la même exigence à un OSS fondé sur le bénévolat n’est pas réaliste.
Il ne se produirait que sur les 10 à 20 premières images d’un jeu de 1995, et classer cela en « gravité moyenne » me paraît exagéré.
Cela ressemble à un cas qui fait perdre du temps aux mainteneurs.
Si c’est grave, mieux vaut que n’importe qui le signale ; si c’est mineur ou erroné, on peut l’ignorer.
Au final, c’est au projet lui-même de décider quels bugs corriger.
Je soutiens la position de l’équipe FFmpeg. Beaucoup d’entreprises n’utilisent le FOSS que pour leur blanchiment d’image marketing, sans contribuer en retour.
Autrefois, certaines auraient simplement piraté le logiciel ; aujourd’hui, la licence leur permet de l’utiliser sans mauvaise conscience.
Tester même des codecs qui ne sont pas utilisés en interne relève d’un objectif d’intérêt général.
Bien sûr, Google a les moyens de financer davantage FFmpeg, mais je ne suis pas d’accord avec l’idée de verser directement de l’argent à ce mainteneur précis cette fois-ci.
On peut l’utiliser librement, mais cela laisse aussi de la place aux abus.
On reproche parfois à la GPL 3 d’aller trop loin, mais au moins elle avait l’intention d’empêcher l’exploitation.
Il y a des gens qui créent gratuitement des logiciels qui définissent une époque, et des entreprises qui s’en servent pour en extraire toute la valeur.
Les premiers agissent par amour, les secondes par transaction.
La divulgation publique des vulnérabilités est nécessaire pour les grandes entreprises, mais pour un OSS aux ressources limitées, les risques peuvent être plus grands.
Si Google veut des corrections rapides, il n’a qu’à soumettre aussi le patch, et tout le monde y gagne.
Surtout s’il s’agit de vulnérabilités qu’un LLM peut découvrir, elles finiront probablement par être exploitées un jour.
Grâce à la divulgation, les utilisateurs peuvent se défendre eux-mêmes, et si FFmpeg a décidé de corriger cela, c’est un choix volontaire.
La recherche en sécurité est elle-même une forme de contribution coûteuse à l’open source.
Dire aux chercheurs que « leur contribution n’est pas suffisante », c’est en réalité exiger du travail gratuit de la part de bénévoles.
La transparence du FOSS aide au contraire à une meilleure prise de conscience de la sécurité.
Elle ne reconnaît pas les zones grises du réel.
Si « un seul e-mail peut arrêter trois lignes de produits », alors un soutien annuel de 10 000 à 20 000 dollars paraît largement suffisant comme assurance.
Si Google et Amazon versaient seulement 50 000 dollars chacun, les développeurs de FFmpeg pourraient travailler de manière stable ;
et Google, qui fait tourner YouTube, pourrait sans difficulté monter à 100 000 voire 200 000 dollars.
Je partage ce fil Twitter où un responsable sécurité de Google récapitule les contributions de l’entreprise à FFmpeg.
Qu’une entreprise valant mille milliards de dollars manque de personnel ou d’argent n’est pas crédible.
Je me demande quel est l’objectif de Project Zero.
J’aimerais savoir s’il y a autre chose derrière que la simple recherche de vulnérabilités.
En même temps, c’est utile pour attirer des talents en sécurité et gérer sa réputation.
Mais si l’entreprise a les moyens de faire cela, elle devrait aussi investir dans la rédaction de patchs.
La vulnérabilité en question était un Use After Free, et c’est l’IA de Google qui l’a trouvée.
Pourtant, il s’agissait d’un correctif qui aurait pu prendre moins de 3 secondes.
Voir une entreprise pleine d’argent balancer des rapports de bugs assimilables à du spam sur un projet bénévole est agaçant.
Cela ne méritait même pas d’être classé comme CVE ; un simple rapport de bug aurait suffi.
free».Éviter une fuite mémoire demande un correctif plus complexe.
Il est probable que la bonne direction soit de laisser ce codec désactivé par défaut.
On leur a donné à manger, et maintenant ils réclament le baluchon.
Les rapports de bugs sont pourtant clairement une contribution importante...
On dirait un peu la situation où quelqu’un nettoie bénévolement le quartier, et où le notable qui possède le plus de terrains dans le coin vient lui dire : « Il y a un mégot de cigarette là-bas, dans le coin. »
Je pense aussi que cette analogie est juste.
C'est une analogie appropriée.
C’est vraiment quelque chose qu’on peut leur reprocher ? À lire le texte, il s’agit d’une vulnérabilité de sécurité d’importance moyenne, qui n’est exploitable que pendant les 10 à 20 premières images d’un jeu très ancien et bien précis. Pensez-vous sincèrement que cela constitue une contribution importante du côté de Google pour FFmpeg ? La contribution la plus importante à une communauté open source, c’est de la soutenir pour permettre un développement stable ; surtout pour une entreprise qui utilise largement ce résultat, cela devrait passer en priorité, non ?
C’est à cause de ce genre de personnes qu’une porte dérobée a été introduite dans XZ.
Le bug report en lui-même est de niveau S, mais ils vont partout raconter qu’une vulnérabilité critique d’un format vidéo de l’époque du président Kennedy n’a pas pu être traitée dans les délais.
Au lieu de donner quelque chose qu’on peut manger, ils donnent quelque chose qu’on est obligé de manger, puis demandent pourquoi on n’a pas réussi à le manger dans les temps.
FFmpeg a des ressources humaines limitées ; est-il vraiment juste que Google, en déversant via l’IA des dizaines de bug reports sur des formats qui ne sont même plus utilisés, fasse pression pour qu’ils soient tous corrigés dans les délais ?