Connexion Abonnez-vous

FFmpeg, Google et la « bouillie » des rapports de bugs générés par IA

Multiplier pour grapiller

FFmpeg, Google et la « bouillie » des rapports de bugs générés par IA

Des échanges pimentés ont eu lieu ces dernières semaines entre le projet open source FFmpeg, Google et plusieurs experts en sécurité. Au cœur du débat, le signalement d’un trop grand nombre de problèmes par Google jugés secondaires par l’équipe de FFmpeg. Les discussions houleuses sur le sujet illustrent la problématique du sous-financement des briques logicielles open source essentielles.

Le 14 novembre à 16h00

FFmpeg est un composant omniprésent, même si vous n’avez jamais croisé sa route. Il est discret, mais il est partout : dans presque tous les navigateurs, VLC, ou encore des produits comme Kodi et Plex. Ce framework, écrit en assembleur, a pour mission de lire et transcoder tous les formats vidéo existants. Il est considéré depuis longtemps comme robuste et très performant.

Cette ubiquité et ces louanges masquent cependant une réalité : FFmpeg est développé par une équipe de bénévoles. Comme de nombreuses briques open source, son financement est difficile et les dons sont essentiels. Une situation mise de nouveau en lumière à la faveur d’un « simple » signalement de sécurité.

Colère montante

Mi-octobre, le compte X de FFmpeg publie plusieurs messages où filtre la colère. On peut lire par exemple que le projet a été accepté par l’initiative européenne YesWeHack pour faciliter la découverte de failles de sécurité. « Aucune réflexion n’a été menée sur le financement des bénévoles qui doivent corriger les bugs gratuitement », ajoute cependant le message.

Dans la foulée, un autre message mettait en avant le cas de Nick Wellnhofer, mainteneur principal de la bibliothèque libxml2, qui critiquait le circuit habituel des signalements de failles de sécurité, autant que le fonctionnement peu ouvert de la Linux Foundation. Il s’en prenait en particulier à Google, dont le Project Zero, décrit comme ce qu’on peut se payer de mieux dans le domaine de la recherche de failles de sécurité, mais venant respirer « sur la nuque des bénévoles ». D'autant plus avec sa politique stricte de publication des détails au bout de 90 jours si aucun correctif n'a été fourni.

Il reste 83% de l'article à découvrir.

Déjà abonné ? Se connecter

Cadenas en colère - Contenu premium

Soutenez un journalisme indépendant,
libre de ton, sans pub et sans reproche.

Accédez en illimité aux articles

Profitez d'un média expert et unique

Intégrez la communauté et prenez part aux débats

Partagez des articles premium à vos contacts

Commentaires (46)

votre avatar
Un problème largement sous-estimé à l'heure actuelle AMHA.
votre avatar
Le gros problème n'est pas seulement la remontée de bugs, mais surtout la Disclosure Policy de Project Zero. Les informations sur les failles sont rendues publiques au bout de 90 jours si l'équipe FFmpeg ne fournit pas un correctif, mettant la pression au projet. Dans le cas de LucasArts Smush cette pression n'est vraiment pas nécessaire pour un codec que presque personne n'utilise.
votre avatar
Exact, je viens d'ajouter une mention à ce sujet :chinois:
votre avatar
"Ce framework, écrit en assembleur, " impressionnant !
votre avatar
Dans une interview de JB Kempf, il disait que le délai pour rendre une image est tellement court, que seul un langage comme ça peut le faire.
votre avatar
Nuance : FFmpeg est écrit en C, mais de nombreux codecs et routines ont des optimisations assembleur.
votre avatar
Si l'IA découvre le bug, elle peux pas proposer un patch aussi tant qu'elle y est ?
Après ça vaudra ce que ça vaudra, mais sur la masse de problèmes triviaux...
votre avatar
Surtout quand Chrome et YT, se servent gratuitement dudit produit :censored:
votre avatar
Les captcha antirobots sont passables par les IA ?
votre avatar
Ils ont servi à entraîner les modèles de vision et d'OCR, donc oui.

(un système anti robot qui a servi a entraîner des robots, la connerie à l'état pure)
votre avatar
C'est inexact de dire que le framework ffmpeg est écrit en assembleur. Certains bouts, oui, probablement. Mais globalement, le projet est écrit en C (suffit d'aller voir le dépôt du code source)
votre avatar

C 90.0%
Assembly 8.1%
Makefile 1.3%
C++ 0.3%
Objective-C 0.1%
Cuda 0.1%
Other 0.1%

d’après le dépôt.
quand même sacrément impressionnant !
votre avatar
Tout est fait en C, effectivement, mais c'est un des rares projets à encore optimiser son code en assembleur. Notamment la bibliothèque dAV1d, qui est devenu le standart de la décompression de l'AV1, a été réécrite dans plusieurs architectures, en assembleur.
https://jbkempf.com/blog/2023/dav1d-1.2.0/
votre avatar
Oui, Google se base sur FFmpeg pour Chrome et donc ChromeOS, mais surtout utilise FFmpeg pour Youtube ! Et donc, Google gagne pleins d'argent grace notamment à FFmpeg. D'où la question de la rémunération. (d'ailleurs, la très grande majorité des sites de streams utilisent FFmpeg. Yt, Netflix, Amazon…)

Du coup là, franchement, c'est dégueulasse de la part de Google de faire un rapport de bug, en IA (donc à la va vite), sur un codec jamais utilisé, en mettant la pression sur les devs pour corriger en 90 jours. Mettre la pression sur des bénévoles (donc non payés) quand t'es Google, ça la fout mal quand même.
votre avatar
Après, il est peut-être possible pour ce type de projet de changer de licence pour que toutes les nouvelles versions soient payantes pour les grosses entreprises. Ainsi, Google n'aurai que 3 choix : s'asseoir sur FFmpeg et devoir en refaire un équivalent du début, ou abandonner l'idée d'avoir les dernières versions, ou payer (et ainsi pouvoir dire fièrement "je contribue au projet").
votre avatar
C'est probablement pas possible : pour que ça se fasse, il faudrait recontacter toutes les personnes qui ont contribué au projet, et leurs demander leurs accords pour le changement de licence. Sans compter qu'il y a pleins d'entreprises qui vivent grace à FFmpeg (en vendant un packaging spécifique par exemple).
De plus, je suis pas sûr que ce serait dans l'intérêt de FFmpeg : un fork ne ferait que diviser les bénévoles, et rendrait sa "supériorité idéologique" discutable.

Mais son financement est un vrai problème. Quand on voit des entreprises dire "acheter notre solution, elle est plus efficace et facile d'utilisation que FFmpeg" alors que tout ce qu'ils font c'est une surcouche à FFmpeg, tout ça sans filer le moindre sous au projet, y'a de quoi rendre dingue.

N'empêche les gens de FFmpeg (et de VLC) sont quand même des as. Genre pour faire la transcription en assembleur de la bibliothèque dAV1d, ils ont sorti des tutos d'assembleurs de bases, pour former des gens lambda à le faire. C'est un boulot de fous, rien que ça.
Je suis en admiration devant ces gens.
votre avatar
C'est quoi cette histoire de devoir recontacter chaque contributeur ? C'est une obligation légale, ou "seulement" morale ?
votre avatar
Chaque contributeur reste l'auteur de son code. Pour modifier la licence sous laquelle il a été publié, il faut donc son accord. C'est une histoire de droit d'auteur (droit auquel est soumis le code).

Pour un projet, cela signifie donc récupérer l'accord de l'ensemble des contributeurs, ou, à défaut, le retrait de la contribution.

C'est pour cela aussi que maintenant, certains projets demandent à chaque contributeur la "signature" d'un accord cédant certains droits sur la contribution.

Tu pourras trouver un résumé de l'épopée par la plume même de celui qui a été en charge d'un passage de la GPL à la LGPL pour VLC : Jean-Baptiste Kempf
votre avatar
Merci !
Je pensais que quand tu contribuais à un projet libre, tu renonçais automatiquement à tes droits d'auteur, mais j'avais négligé que les droits moraux sont incessibles (au moins en France). 😉
votre avatar
C'est aussi une des raisons qui font que certains projets libres n'acceptent pas les contributions externes : l'auteur peut ainsi changer sa licence comme bon lui semble.
votre avatar
Mais j'y pense : si je contribue à un logiciel dans mon entreprise et que celle-ci décide de changer sa licence, ça veut dire que l'entreprise doit m'en demander l'autorisation ?!
votre avatar
Non, si c'est dans le cadre de ton travail, c'est l'entreprise qui possède les droits (pour les logiciels).
votre avatar
OK, pour les droits patrimoniaux, mais rien n'est dit sur le droit moral.
Or, si je comprends bien, le problème au niveau du logiciel libre, c'est justement le droit moral : les droits patrimoniaux sont abandonnés lorsque la licence appliquée est libre, si je ne m'abuse.
votre avatar
votre avatar
les droits patrimoniaux sont abandonnés lorsque la licence appliquée est libre
Non. Ce sont même eux qui font qu'en tant que "propriétaire" des lignes de code que tu as écrit, tu donnes le droit aux utilisateurs de les copier, diffuser ou je ne sais quoi d'autre suivant la licence.
votre avatar
Il y a une chose qui m'échappe : les droits patrimoniaux permettent à l'auteur de déterminer qui a le droit de reproduire son œuvre (dans le libre, c'est tout le monde), de représenter l'œuvre (dans le libre, c'est tout le monde), de distribuer l'œuvre (dans le libre, c'est tout le monde).
Il lui reste quoi, comme droit patrimonial, à l'auteur, une fois qu'il a libéré son code ?

Peut-être que, légalement, il reste le titulaire des droits patriminiaux, mais dans la pratique, il n'a plus aucune maîtrise.

C'est ça qui m'étonne.
Après, au vu des efforts mis par LibreOffice pour se débarrasser du code de OpenOffice pour des questions de licence, j'imagine qu'il y a bien un blocage juridique quelque part que je ne saisi pas.


Édit : j'ai demandé à Lumo, et la distinction se fait sur le fait qu'il n'y a sue les auteurs qui peuvent donner une licence sur leur œuvre. Et donc en changer reviennant à donner une nouvelle licence, seuls les auteurs peuvent le faire, et donc il faut que TOUS y consentent (sauf à dégager le code fait pas le seul auteur qui veut pas accepter le changement de licence ^^).
votre avatar
qui a le droit de reproduire son œuvre (dans le libre, c'est tout le monde), de représenter l'œuvre (dans le libre, c'est tout le monde), de distribuer l'œuvre (dans le libre, c'est tout le monde).
C'est pas tout à fait ça.
Là, tu décris le domaine public qui est une petite partie du libre (catégories de logiciels).
Il lui reste quoi, comme droit patrimonial, à l'auteur, une fois qu'il a libéré son code ?
Pour le domaine public : rien, que le droit moral.


Sinon, pour le reste du libre :
Les logiciels libres sont soumis, comme tout logiciel publié hors du domaine public, au droit d'auteur. Dans ce cadre, le droit d'auteur est exercé par le biais d'une licence libre qui énumère les droits que l'auteur choisit d'octroyer à l'utilisateur.
votre avatar
Changer de licence ainsi n'est pas évident (VLC en sait quelque chose pour avoir changé de licence dans le passé).

Qui plus est, une telle licence (payante dans certains cas) ne serait pas libre. Et même si la licence est "presque libre", une partir de la communauté du libre est très bruyante sur ce genre de sujet. Il suffit de regarder le remus ménage fait par des projets massivement utilisés par des opérateurs du cloud quand ils ont changé de licence pour la SSPF par exemple.
votre avatar
Je suis d'accord avec toi. Cependant, il y a un moment où le principe de réalité s'applique, malheureusement.
votre avatar
Cela me rappelle l'incident d'OpenSSL, largement utilisé par les GAFAM, décrié avec la faille HeartBeat.

À quand un % de développeur dédié sur un projet générant un gros profit ? (ou une collaboration au logiciel libre)
votre avatar
Il faut savoir se préserver quand on est bénévol pour éviter d'exploser en vol.

Mon conseil pour les mainteneurs: faire juste le travail que l'on estime raisonnable de faire et accepter de ne pas être un super héro.

Réponse type à envoyer en automatique à google: ce sera fait quand j'aurais le temps, signé avec un doigt d'honneur en ascii art.

Et un nota bene: la boîte â bug sera réinitalisée en cas de dépassement de la limite. Si vous envoyez trop de message, tout sera effacé. Merci.
votre avatar
Le problème ici, c'est que c'était un CVE.
Ce qui veut dire que si ce bug n'était pas corrigé dans les 90 jours (suivant la politique de Google) :
1. FFmpeg passe pour un logiciel "dangereux", avec des failles critiques
2. Un attaquant pourrait récupérer les infos de ce CVE divulgué, et créer une vidéo qui utilise ce problème, et rendre le problème réellement dangereux.

Le problème c'est pas le bug en tant que tel, c'est la politique des 90 jours.
votre avatar
Cela ne change strictement rien au fait qu'il faut qu'ils se ménagent et que personne n'a à leur mettre la pression car c'est un logiciel gratuit et open source.

Si cela doit partir en couilles: rien à foutre, ce n'est pas leur responsabilité. Personne n'a à leur mettre la pression (sauf éventuellement celle qui se boit).

1, si FFmpeg passe pour un logiciel dangereux, que va-t-il se passer vu qu'il n'y a pas d'alternative de même envergure ?
2. Si Google rend publique les failles et qu'elles sont massivement exploités, ils seront coupable d'avoir fourni des éléments décisifs pour aider les pirates et donc co-responsables des dégâts occasionnés.

La politique des 90 jours, c'est le problème et la responsabilité de Google et de personne d'autre.
votre avatar
Si ffmpeg passe pour un logiciel dangereux, que deviennent les produits Google qui l'utilisent ?
votre avatar
C'est pour moi du même niveau que les gens qui mettent la pression sur des asso et les bénévoles (genre repare café ou autre). Si ça te plaît pas, et bien c'est le même prix comme c'est gratuit. Si j'étais maintainer, je ferais ce que je peux et si ça implique de laisser des failles se disclose, so what. Si ça horrifie les gros user d'utiliser des outils troué qu'ils ne paient pas. Et bien ils sont les bienvenus pour corriger avec leur super IA
votre avatar
Ça reste pas si simple : un projet open source auquel tu contribue, c'est un peu ton bébé et tu veux en prendre soin. Si on te dit "il y a un problème", tu as envie de le corriger. Mais si d'un coup on te dis "il y a 30 problèmes", ça peut te démoraliser.
votre avatar
Bien d'accord, je suis moi-même bénévole et épuisé.

Et avec cette fatigue et les comportements gerbants des personnes qui profitent des associations avec des exigences que l'on pourrait éventuellement avoir de société commerciale, j'ai de plus en plus de détachement.

Je n'ai pas de temps à perdre pour les cons.
votre avatar
Les récompenses de la chasse aux bug sur les projets open source ne devraient être donné que si tu as proposé un correctif validé et intégré, ça ferait les pieds
votre avatar
Ça serait contre-productif car les soumissionnaires iraient alors mettre la pression aux mainteneurs...
votre avatar
Si tu viens avec un patch, j’appelle pas ça « mettre la pression », au contraire.

Je trouve effectivement que financer la découverte, mais pas la correction, correspond bien à l’idée que trouver des failles est beaucoup plus coûteux que les corriger, ce qui est le plus souvent vrai, mais néglige quand même un peu trop l’aspect correction.
votre avatar
Non, ce que je veux dire c'est que le soumissionnaire du patch mettrait la pression aux mainteneurs pour qu'ils valident sa PR le plus vite possible pour qu'il puisse avoir sa récompense.
votre avatar
Merci Vincent pour cet article, je ne connaissais pas le sujet c'est intéressant
Ca m'a rappelé l'échange qu'il y a eu a propos de log4j ou des grosses société avait contacté le dev bénévole pour lui demander un délai et une correction rapide
J'admire tout ces gars, c'est des passionnés mais même s'ils sont conscients et sûrement fiers de ce que implique la licence openssource, je comprends que voir utiliser ton travail massivement par des grands groupes sans aucune contrepartie est démoralisant
votre avatar
C'est pour ça, qu'amha, quand on s'appelle Google et qu'on se sert d'un produit gratuit pour se gaver dans ses services ou logiciels, on devrait contacter les dev avec une solution, avant de publier le problème de sécurité. En plus, en terme de com, ce serait une manière de dire : on est pas des méchants, regardez, on n'abuse pas des dev passionnés qui bossent gratuitement sur cet outil indispensable, on les aide.
votre avatar
on est pas des méchants
Don't be evil, c'est fini depuis belle lurette chez Alphabet. C'est devenu une multinationale toxique comme toutes les autres (si tant est qu'elle ne l'ait pas été avant).
votre avatar
Je suis bien d'accord. Je suis étonné qu'il n'essaye même pas de se donner une bonne image.
votre avatar
Tous ces sujets d'exploitation (du travail) de passionnés reviennet toujours au fait que la mentalité d'extraction ne voit pas le problème à pomper le travail d'un autre sans juste contrepartie, le tout en étant qui-plus-est exigeant vis-à-vis de cet autre.
Je ne vois pas comment des communs pourraient être défendus ailleurs que dans l'espace public.

Il faudrait que des institutions, par exemple en commençant par les nôtres, s'emparent du sujet de la protection du travail, et mènent une réflexion sur le financement de telles initiatives, comme le libre.
Il n 'y a pas si longtemps étaient encore évoquées des pistes comme le revenu universel ou une licence universelle (mêmes si des détails de rouages font passer par des réflexions différentes).

Le travail ne devrait légalement plus être considéré comme uniquement le fruit d'un emploi, car de tout temps une quantité incroyable de travail est effectué en-dehors de ce carcan.
Les communs représentent une part considérable dans notre existence, bien plus que chacun le soupçonne, au point qu'elle serait impossible sans. Si demain les profiteurs se trouvaient coupés des communs, tout, absolument tout, s'effondrerait.

La valorisation du travail passe aussi par sa protection contre la prédation/l'extraction de la part des rentiers, profiteurs habituels aspirant le travail des autres sans correctement ni rémunérer ni contribuer.
Cela tombe bien : depuis les débuts, Stallman et sa FSF militent pour la protection/garantie des droits par licence.
Sauf que… pour qu'un droit soit applicable, il faut que des moyens de l'appliquer existent, c'est tout l'équilibre fragile qui commence à nouveau à avoir été récemment mis en échec que l'on peut observer au niveau des lois internationales. Si donc, notre législation et notre appareil judiciaire s'attachaient à permettre l'application (et donc la défense par l'attaque des extracteurs) de ces licences, cela ouvrirait rapidement la discussion sur le préjudice, donc le financement du travail non-salarié.

L'application de cette législation pourrait très facilement déboucher sur de la régulation concernant l'utilisation de communs par des structures à but lucratif. Ce serait sans nulle doute une pilule vertigineusement difficile à avaler pour les profiteurs qui ne voient pas le problème de pomper le travail du libre en ne le considérant que comme "gratuitement utilisable", ce qu'il n'est pourtant pas sans strictes conditions.
Mais quand on voit que c'est mission impossible de récupérer une fraction infinitésimale d'une richesse bien trop grande pour être à la fois honnête & utile dans le pot commun profitable à tous… d'un coup, d'un seul, la dichotomie devient le Grand Canyon.

Tout les ingrédients sont là : culture libre, licence en protégeant le fruit, commun installés couvrant tout un tas de savoir(-faire), passionnés faisant vivre des projets du bout de leurs brindilles.
Il ne manque donc plus "que" :
- une culture informatique dans la société, puis amenée/appuyée au niveau des représentants politiques
- une culture du libre dans la société, puis amenée/appuyée au niveau des représentants politiques
- une volonté politique qui retrouve la seule raison d'être d'un État : la défense des plus faibles éléments de la Nation

Cela peut prendre quelques mois ou quelques millénaires, selon si l'on est plutôt optimiste ou désabusé.

FFmpeg, Google et la « bouillie » des rapports de bugs générés par IA

  • Colère montante

  • L’élément déclencheur

  • Un gigantesque fossé dans les points de vue

  • L’épuisement de tout un système ?

Fermer