Discussion :

[Stéphane le calme]

L'open source est-il en danger ? Les mainteneurs de logiciels libres sont noyés dans des rapports de bogues inutiles rédigés par l'IA,
« ces systèmes ne sont pas encore capables de comprendre le code », estime un développeur

Les soumissions de vulnérabilités logicielles générées par des modèles d'IA ont inauguré une « nouvelle ère de rapports de sécurité bâclés pour l'open source » - et les développeurs qui maintiennent ces projets souhaiteraient que les chasseurs de bogues s'appuient moins sur les résultats produits par les assistants d'apprentissage automatique.

Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blog la semaine dernière, exhortant les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. « Récemment, j'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par LLM dans les projets open source », écrit-il, rappelant les résultats similaires obtenus par le projet Curl en janvier. « Ces rapports semblent à première vue potentiellement légitimes et nécessitent donc du temps pour être réfutés ».

Larson estime que les rapports de mauvaise qualité doivent être traités comme s'ils étaient malveillants.

Une montée en flèche des rapports automatisés

Les mainteneurs jouent un rôle essentiel dans l'univers de l'open source. Ces bénévoles consacrent leur temps et leur expertise à maintenir des projets utilisés par des millions de personnes à travers le monde. Pourtant, ces derniers mois, un phénomène inquiétant perturbe leur travail : une multiplication des rapports de bogues de mauvaise qualité générés par des intelligences artificielles (IA).

Avec l’essor des outils d'IA comme ChatGPT, Bard ou Copilot, il est devenu plus facile que jamais pour les utilisateurs de générer des rapports de bogues. Ces outils, bien qu’impressionnants, génèrent parfois des rapports qui manquent de pertinence, sont mal formulés ou complètement hors sujet. Résultat : les mainteneurs se retrouvent à gérer une quantité croissante de « bruit », au détriment des problèmes légitimes.

Les mainteneurs rapportent une tendance claire : des rapports contenant des descriptions vagues, des solutions proposées incorrectes, ou des erreurs inexistantes. Dans certains cas, des IA « inventent » des problèmes à partir d’une compréhension superficielle du code. Ces rapports peuvent sembler crédibles, mais nécessitent souvent un temps considérable pour être vérifiés et écartés.

Une pression accrue sur les mainteneurs

Ce phénomène exacerbe une charge de travail déjà lourde. Beaucoup de mainteneurs sont des bénévoles qui jonglent entre leur travail, leur vie personnelle, et leurs responsabilités dans des projets open source. Traiter des rapports inutiles prend du temps, fatigue émotionnellement et peut entraîner un épuisement professionnel.

En outre, ces rapports nuisent aux discussions communautaires. Lorsque les canaux de communication sont saturés de contenu généré par l’IA, il devient plus difficile pour les utilisateurs humains de se faire entendre.

Pour Seth Larson, cette tendance est très préoccupante

Je fais partie de l'équipe de triage des rapports de sécurité pour CPython, pip, urllib3, Requests et une poignée d'autres projets open source. J'occupe également une position de confiance qui me permet d'être « étiqueté » dans d'autres projets open source pour aider les autres lorsqu'ils ont besoin d'aide en matière de sécurité.

Récemment, j'ai remarqué une augmentation des rapports de sécurité de très mauvaise qualité, spammés et hallucinés par le LLM dans les projets open source. Le problème est qu'à l'ère des LLM, ces rapports semblent à première vue potentiellement légitimes et nécessitent donc du temps pour être réfutés. D'autres projets tels que curl ont fait état de résultats similaires.

Certains rapporteurs utiliseront divers outils d'analyse de sécurité et ouvriront des rapports de vulnérabilité sur la base des résultats obtenus, apparemment sans le moindre esprit critique. Par exemple, urllib3 a récemment reçu un rapport parce qu'un outil détectait notre utilisation de SSLv2 comme non sécurisée alors que notre usage est de désactiver explicitement SSLv2.

Il est difficile de s'attaquer à ce problème car il est réparti sur des milliers de projets open source et, en raison de la nature sensible de la sécurité des rapports, les mainteneurs open source sont découragés de partager leurs expériences ou de demander de l'aide. Le partage d'expériences demande du temps et des efforts, ce qui est une denrée rare chez les mainteneurs.

Et d'estimer que répondre aux rapports de sécurité coûte cher :

« Si cela arrive à une poignée de projets pour lesquels j'ai de la visibilité, alors je soupçonne que cela arrive à grande échelle aux projets open source. Cette tendance est très préoccupante.

« La sécurité est déjà un sujet qui n'est pas aligné avec la raison pour laquelle de nombreux mainteneurs donnent de leur temps aux logiciels open source, considérant plutôt la sécurité comme importante pour aider à protéger leurs utilisateurs. En tant que rapporteurs, il est essentiel de respecter ce temps souvent bénévole.

« Les rapports de sécurité qui font perdre du temps aux mainteneurs sont source de confusion, de stress, de frustration et, pour couronner le tout, d'un sentiment d'isolement dû à la nature secrète des rapports de sécurité. Tous ces sentiments peuvent contribuer à l'épuisement des contributeurs aux projets open source, qui jouissent probablement d'une grande confiance.

« À bien des égards, ces rapports de mauvaise qualité devraient être traités comme s'ils étaient malveillants. Même si ce n'est pas leur intention, le résultat est que les mainteneurs sont épuisés et plus réticents au travail de sécurité légitime ».

L'illustration de la persistance de ces préoccupations avec un rapport de bogue du projet Curl

Comme pour souligner la persistance de ces préoccupations, un rapport de bogue du projet Curl publié le 8 décembre montre que près d'un an après que le responsable Daniel Stenberg a soulevé le problème, il est toujours confronté à la « lenteur de l'IA » - et perd son temps à discuter avec un auteur de bogue qui pourrait être partiellement ou entièrement automatisé.

En réponse au rapport de bogue, Stenberg a écrit :

« Nous recevons régulièrement et en grand nombre des erreurs d'IA de ce type. Vous contribuez à [la] charge inutile des mainteneurs de Curl et je refuse de prendre cela à la légère et je suis déterminé à agir rapidement contre cela. Maintenant et à l'avenir.

« Vous avez soumis ce qui semble être un "rapport" d'IA évident où vous dites qu'il y a un problème de sécurité, probablement parce qu'une IA vous a trompé en vous faisant croire cela. Vous nous faites ensuite perdre notre temps en ne nous disant pas qu'une IA a fait cela pour vous et vous poursuivez la discussion avec des réponses encore plus merdiques - apparemment générées elles aussi par une IA

« Il est tout à fait possible d'utiliser l'IA pour apprendre des choses et résoudre des problèmes potentiels, mais lorsque vous supposez aveuglément qu'un outil stupide est automatiquement juste parce qu'il semble plausible, vous nous rendez à tous (le projet curl, le monde, la communauté open source) un très mauvais service. Vous auriez dû étudier l'affirmation et la vérifier avant de la rapporter. Vous auriez dû nous dire qu'une IA vous l'avait signalée. Vous auriez dû fournir l'emplacement exact du code source ou les étapes de la reproduction lorsqu'on vous l'a demandé - parce que lorsque vous ne l'avez pas fait, vous avez prouvé que votre "rapport" n'avait aucune valeur particulière ».

« Ces systèmes ne sont pas encore capables de comprendre le code »

Les contenus en ligne polluants et de mauvaise qualité existaient bien avant les chatbots, mais les modèles d'IA générative ont facilité leur production. Il en résulte une pollution du journalisme, de la recherche sur le web et, bien sûr, des médias sociaux.

Pour les projets open source, les rapports de bogues assistés par l'IA sont particulièrement pernicieux car ils nécessitent l'examen et l'évaluation d'ingénieurs en sécurité - souvent bénévoles - qui sont déjà pressés par le temps.

« Ce qui arrive à Python ou à Pip est susceptible d'arriver à d'autres projets ou plus fréquemment », a averti Larson. « Je suis surtout préoccupé par les mainteneurs qui gèrent cela de manière isolée. S'ils ne savent pas que les rapports générés par l'IA sont monnaie courante, ils pourraient ne pas être en mesure de reconnaître ce qui se passe avant de perdre des tonnes de temps sur un faux rapport. Perdre un temps précieux de bénévolat à faire quelque chose que vous n'aimez pas et en fin de compte pour rien est le moyen le plus sûr d'épuiser les mainteneurs ou de les éloigner du travail de sécurité ».

Selon Larson, la communauté des logiciels libres doit prendre de l'avance sur cette tendance afin d'atténuer les dommages potentiels.

« J'hésite à dire que le problème sera résolu par plus de technologie », a-t-il déclaré. « Je pense que la sécurité des logiciels libres a besoin de changements fondamentaux. Nous ne pouvons pas continuer à confier le travail à un petit nombre de mainteneurs, et nous avons besoin d'une normalisation et d'une visibilité accrues de ces types de contributions à l'open source ».

« Nous devrions répondre à la question suivante : "Comment impliquer davantage de personnes de confiance dans l'open source ?" Le financement du personnel est une réponse - comme ma propre subvention par Alpha-Omega - et l'implication par le don de temps de travail en est une autre ».

Alors que la communauté du logiciel libre réfléchit à la manière de réagir, Larson demande aux personnes qui soumettent des rapports de bogues de ne pas le faire s'ils n'ont pas été vérifiés par un être humain - et de ne pas utiliser l'IA, car « ces systèmes ne sont pas encore capables de comprendre le code ». Il invite également les plateformes qui acceptent les rapports de vulnérabilité au nom des mainteneurs à prendre des mesures pour limiter la création automatisée ou abusive de rapports de sécurité.

Sources : Seth Larson, rapport de bogue,

Et vous ?

Quelle lecture faites-vous de la situation ? Trouvez-vous l'analyse de Seth Larson crédible ou pertinente ? Dans quelle mesure ?

Quelles implications imaginez-vous si la situation perdure et s'aggrave ?

Quelles solutions pourraient être mises en place pour mieux soutenir les mainteneurs face à cette surcharge ?

Les utilisateurs d’IA sont-ils suffisamment formés à soumettre des rapports de qualité ? Qui devrait se charger de cette éducation ?

Les IA pourraient-elles, au contraire, être utilisées pour filtrer les rapports de mauvaise qualité ? Si oui, comment éviter les biais dans leur utilisation ?

Le phénomène des rapports générés par IA remet-il en question la viabilité du modèle open source tel qu’il existe aujourd’hui ?

[popo]

Quelle lecture faites-vous de la situation ? Trouvez-vous l'analyse de Seth Larson crédible ou pertinente ? Dans quelle mesure ?

J'approuve totalement cette analogie.
J'ai moi même pu constater le problème de ces rapports de bogues générés par des IA.
Tu prend du temps pour analyser, et lorsque tu demandes un complément d'informations pour reproduire, la personne botte en touche ou bien te fourni une informations qui ne permet pas de reproduire.
J'ai personnellement blacklisté plusieurs personnes, dont j'ignore désormais les rapports.

Quelles implications imaginez-vous si la situation perdure et s'aggrave ?

J'imagine qu'à force, la plupart des mainteneurs finiront pas ignorer les rapports "rédigés" par certaines personnes, comme je le fait déjà.
C'est dommage car, si dans le lot, il y en a un qui est légitime, il risque de ne pas être corrigé.

Ou alors, les mainteneurs finiront pas abandonner.
Ce qui serait beaucoup plus grave.
Je pense que Seth Larson a raison de considérer ces rapports comme malveillant.
Car si les mainteneurs abandonnent, cela fera l'affaire des personnes malveillantes qui se servent des failles non corrigées.
Il est n'est donc pas impossible que ces rapports soit "rédigés" par des personnes malveillantes tentant de saper le moral des mainteneurs.

Quelles solutions pourraient être mises en place pour mieux soutenir les mainteneurs face à cette surcharge ?

Cette solution n'est clairement pas viable à long terme.
Mais, personnellement j'établirais une norme permettant d'analyser de manière automatique la partie du rapport qui traite de la manière de reproduire, et j'ignorerais de manière systématique tout rapport qui en serait dépourvu.

Les utilisateurs d’IA sont-ils suffisamment formés à soumettre des rapports de qualité ? Qui devrait se charger de cette éducation ?

Je pense que ceux qui soumettent des rapports de qualité généré par une IA, savent très bien ce qu'ils font.
Je suis d'avis que le "Même si ce n'est pas leur intention" de Seth Larson est plutôt naïf, et que c'est justement l'objectif de personnes malveillantes de faire crouler les mainteneurs sous une montagne de faux rapport, dans l'objectif de les décourager ou de les mettre sous une pression telle, qu'il feront plus d'erreurs.

Les IA pourraient-elles, au contraire, être utilisées pour filtrer les rapports de mauvaise qualité ? Si oui, comment éviter les biais dans leur utilisation ?

Pour cela, il faudrait une IA capable de détecter les fausses informations dans ces rapports.
Mais puisque ces rapports sont sensés être une source fiable, sur quoi va-t-elle se baser pour distinguer le vrai du faux ?
Donc, en l'état actuel, avec la manière dont fonctionnent les IA, je ne pense pas que cela soit réalisable.

Le phénomène des rapports générés par IA remet-il en question la viabilité du modèle open source tel qu’il existe aujourd’hui ?

A plus ou moins long terme, à forcer d'épuiser les mainteneurs, je suis d'avis qu'il arrivera un moment où, pour se fier à une librairie open source, il faudra passer énormément de temps à analyser son code et à effectuer des tests pour en garantir la sécurité à un instant T. Et, comme en règle générale, on utilise des librairies pour gagner du temps ou parce qu'on n'est pas à l'aise sur le sujet traité par la librairie, cela va vite devenir contreproductif.
Je suis d'avis que cela pourrait probablement conduire (faute de confiance) à l'arrêt du modèle open tel qu'on le connait.

[Zefling]

En tout cas, ils s'intéressent pas aux petits projets.
Et j'ai viré toud les fichiers comme « package-lock.json » de mes projets pour ne plus être spam par les bots qui me disent : il faut mettre à jour ce package.

[nilsb111]

Effectivement, je n'y avais pas pensé, merci pour cet article très intéressant !
J'ai eu une idée de demi-solution, pas très satisfaisante mais potentiellement mieux que rien:
Faire payer chaque report une petite somme (~10€ ?) et rembourser les reports légitimes ou les reports qui n'ont visiblement pas été fait à l'IA et source d'une vrai erreur humaine.
Ça dissuaderait ceux qui voudraient spammer avec des reports...

[Mathis Lucas]

Le projet open source cURL interdit les rapports de bogue inutiles générés par l'IA : « nous n'avons toujours pas vu un seul rapport de sécurité valide rédigé avec l'aide de l'IA »

Les mainteneurs de projets libres et open source sont submergés par des rapports de bogues inutiles rédigés par l'IA. S'ils semblent convaincants en apparence, ces rapports sont souvent basés sur les hallucinations de l'IA et nécessitent un temps considérable pour être vérifiés, ce qui détourne les ressources limitées des développeurs bénévoles. Cette situation peut entraîner une perte de temps, de l'épuisement et une diminution de la motivation des contributeurs bénévoles. Daniel Stenberg, créateur du projet cURL, a surnommé ces rapports de faible qualité « AI slop ». Dans un récent billet, il a formellement interdit les rapports de bogues générés par l'IA.

CURL est un outil et une bibliothèque de ligne de commande essentiels pour interagir avec les ressources Internet. Le projet open source reçoit des rapports de bogues et des problèmes de sécurité par le biais de nombreux canaux, notamment HackerOne, un service de signalement qui aide les entreprises à gérer les rapports de vulnérabilité et les primes aux bogues. Mais les pratiques ont évolué au cours de ces dernières années.

HackerOne s'est passionné pour les outils d'IA. « Une plateforme, une force double : l'esprit humain + la puissance de l'IA », peut-on lire sur sa page d'accueil. Ainsi, les utilisateurs s'appuient de plus en plus sur les outils d'IA de la plateforme pour générer des rapports de bogue et de sécurité.

Un afflux de rapports de bogues de mauve qualité générés par IA

L'adoption des outils d'IA par les plateformes telles que HackerOne pose un problème majeur à la communauté des logiciels libres : la multiplication de rapports de vulnérabilités générés par des outils d'IA, souvent erronés ou trompeurs, qui submergent les mainteneurs. Les fabricants de modèles d'IA s'attendent à ce que l'IA aide les développeurs à détecter les bogues beaucoup plus rapidement afin de jouir de plus de temps pour innover.

Mais il s'avère que ces rapports sont en majorité le résultat des hallucinations de l'IA, et donc inutiles. Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blogue en décembre dernier. Il a exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. Selon lui, les systèmes d'IA actuels ne sont pas fiables dans ce contexte.

« J'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par les LLM dans les projets open source. À première vue, ces rapports de bogue semblent potentiellement légitimes et nécessitent donc du temps pour être réfutés », écrivait-il, rappelant les résultats similaires obtenus par le projet cURL en janvier 2024. Récemment, c'est le créateur du projet cURL qui a exprimé son ras-le-bol :

Voilà, c'est fait. J'en ai assez. Je mets un terme à cette folie.

1. Tous les rapporteurs qui soumettent des rapports de sécurité sur le hashtag#Hackerone pour le hashtag#curl doivent désormais répondre à cette question : « avez-vous utilisé une IA pour trouver le problème ou générer cette soumission ? »

(Et s'ils le sélectionnent, ils peuvent s'attendre à un flot de questions de suivi prouvant l'existence d'une intelligence réelle.)

2. Nous bannissons INSTANTANÉMENT tous les rapporteurs qui soumettent des rapports que nous considérons comme un déchet généré par l'IA. Un seuil a été atteint. Nous sommes effectivement victimes d'un DDoS. Si nous le pouvions, nous les ferions payer pour cette perte de temps.

Nous n'avons toujours pas vu un seul rapport de sécurité valide réalisé avec l'aide de l'IA.

Dans certains cas, les auteurs des signalements erronés sont des personnes novices qui testent des IA sur du code. Ou pire, elles utilisent les rapports générés par l'IA pour tenter d'obtenir des récompenses financières via des programmes de primes aux bogues sans fournir de véritables contributions.

Ce phénomène souligne un problème plus général : les projets open source fonctionnent grâce à quelques bénévoles. L’utilisation abusive de l'IA peut nuire à l’écosystème, en gaspillant l'énergie précieuse des personnes qui le maintiennent. L'hallucination des modèles est un problème majeur de l'IA générative auquel les chercheurs n'ont pas encore trouvé de solution. Selon une étude de 2024, l'hallucination est un problème insoluble.

Récemment, quatre rapports de vulnérabilité malavisés, générés par l'IA, ont été publiés, apparemment à la recherche d'une réputation ou d'une prime de détection de bogues. « L'une des façons de s'en rendre compte, c'est que le rapport est toujours très agréable. Formulé de manière agréable, en anglais parfait, poli, avec de jolis points... un humain ordinaire ne le ferait jamais de cette manière dans son premier rapport », a déclaré Daniel Stenberg.

Des signalements de fausses failles de sécurité dans les logiciels

Ce phénomène exacerbe une charge de travail déjà lourde. Beaucoup de mainteneurs sont des bénévoles qui jonglent entre leur travail, leur vie personnelle, et leurs responsabilités dans des projets open source. Traiter des rapports inutiles prend du temps, fatigue émotionnellement et peut entraîner un épuisement professionnel. Seth Larson estime que les rapports de mauvaise qualité doivent être traités comme s'ils étaient malveillants.

« À bien des égards, ces rapports de mauvaise qualité devraient être traités comme s'ils étaient malveillants. Même si ce n'est pas leur intention, le résultat est que les mainteneurs sont épuisés et plus réticents au travail de sécurité légitime », a écrit Seth Larson dans son billet de blogue l'année dernière.

À titre d'exemple, Daniel Stenberg a évoqué un rapport de bogue datant du 4 mai 2025. Il suggérait un « nouvel exploit exploitant les cycles de dépendance de flux dans la pile de protocoles HTTP/3 ». La mauvaise gestion des dépendances de flux, lorsqu'un aspect d'un programme attend la sortie d'un autre aspect, peut conduire à l'injection de données malveillantes, à des conditions de course et à des plantages, ainsi qu'à d'autres problèmes.

Le rapport en question suggère que cela pourrait rendre cURL, qui est compatible avec HTTP/3, vulnérable à des exploits pouvant permettre l'exécution de code à distance. Mais comme le souligne le personnel de cURL, le correctif « configuration de serveur malveillant » soumis ne s'appliquait pas aux dernières versions d'un outil Python en question. Interrogé à ce sujet, l'auteur du signalement a répondu d'une manière étrangement prompte.

Il répondait à des questions qui n'avaient pas été posées par l'équipe de cURL et incluait ce qui semble être des instructions de base sur la manière d'utiliser l'outil git pour appliquer un nouveau correctif. L'auteur du signalement n'a pas non plus fourni le nouveau fichier correctif demandé, a cité des fonctions qui n'existent pas dans les bibliothèques sous-jacentes et a suggéré des tactiques de renforcement pour des utilitaires autres que cURL.

L'équipe de cURL a finalement fermé le rapport, mais l'a également rendu public pour servir d'exemple. Alex Rice, cofondateur, directeur technique et responsable de la sécurité des systèmes d'information de HackerOne, a déclaré que les rapports contenant « des vulnérabilités hallucinées, un contenu technique vague ou incorrect, ou d'autres formes de bruit à faible effort » sont traités comme du spam et font l'objet d'une mise en application.

Conclusion

Les rapports de bogue de mauvaise qualité générés par l'IA sont devenus un problème pour les mainteneurs de logiciels libres et open source. Ce phénomène met en évidence les défis posés par l'utilisation non encadrée de l'IA dans la détection de vulnérabilités. Selon Daniel Stenberg et d'autres, cela souligne la nécessité d'une approche plus rigoureuse et collaborative pour maintenir la qualité et la sécurité des projets libres et open source.

« Je suis très heureux que ce problème attire l'attention afin que nous puissions éventuellement faire quelque chose à ce sujet et éduquer le public sur l'état des choses. Les LLM ne peuvent pas trouver de problèmes de sécurité, du moins pas de la manière dont ils sont utilisés ici », a-t-il déclaré.

Source : Daniel Stenberg

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'utilisation de l'IA pour la détection de problèmes de sécurité ?
Selon vous, les systèmes d'IA actuels sont-ils adaptés à ce cas d'utilisation ? Pourquoi ?
Selon vous, quels impacts ce phénomène pourrait-il avoir sur l'écosystème des logiciels libres et open source ?

Voir aussi

Les mainteneurs de logiciels libres sont noyés dans des rapports de bogues inutiles rédigés par l'IA. « Ces systèmes ne sont pas encore capable de comprendre le code », estime un développeur

L'IA peut écrire du code mais ne parvient pas à le comprendre, selon une étude d'OpenAI. Testés sur des tâches réelles de programmation, les modèles les plus avancés n'ont pu résoudre qu'un quart des défis

Les outils de développement GenAI n'améliorent pas l'efficacité du codage et augmentent le nombre de bogues : avec Microsoft Copilot les développeurs ont constaté une augmentation de 41 % des bogues

[Mathis Lucas]

AI Slop ? Pas cette fois. Un chercheur en sécurité utilise l'IA pour repérer une cinquantaine de bogues réels dans le code du projet open source cURL
démontrant son efficacité sous supervision humaine

Le projet cURL a été confronté à une avalanche de rapports de bogues générés automatiquement par l'IA ces dernières années. Ces rapports sont souvent de faible qualité, souvent incohérents ou non pertinents. Cette situation a entraîné une surcharge de travail pour les mainteneurs, qui avaient donc été contraints d'interdire les rapports de bogues générés par l'IA. Cependant, un chercheur en sécurité a récemment utilisé l'IA pour soumettre des rapports à cURL et ces rapports ont permis d'identifier environ 50 vulnérabilités dans le code. Les mainteneurs ont salué la qualité de ces découvertes, soulignant que l'IA peut aider lorsqu'elle est bien utilisée.

cURL est un outil et une bibliothèque de ligne de commande essentiels pour interagir avec les ressources Internet. Le projet open source reçoit des rapports de bogues et des problèmes de sécurité par le biais de nombreux canaux, notamment HackerOne, un service de signalement qui aide les entreprises à gérer les rapports de vulnérabilité et les primes aux bogues. Mais les pratiques ont évolué au cours de ces deux dernières années.

HackerOne s'est passionné pour les outils d'IA. « Une plateforme, une force double : l'esprit humain + la puissance de l'IA », peut-on lire sur sa page d'accueil. Ainsi, les utilisateurs s'appuient de plus en plus sur les outils d'IA de la plateforme pour générer des rapports de bogue et de sécurité.

Mais il s'avère que ces rapports sont en majorité le résultat des hallucinations de l'IA, et donc inutiles. Seth Larson, expert en cybersécurité en résidence à la Python Software Foundation, a soulevé la question dans un billet de blogue viral en décembre 2024. Il a exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. Selon lui, les systèmes d'IA actuels ne sont pas fiables dans ce contexte.

Les rapports de bogues de mauvaise qualité générés par l'IA ont posé problème non seulement à cURL, mais aussi à la communauté Python, à Open Collective et au projet Mesa. Ce déluge a incité Daniel Stenberg, responsable du projet open source cURL, à publier plusieurs articles de blogue sur le sujet afin de convaincre les chasseurs de bogues de faire preuve de retenue et de ne pas faire perdre de temps aux contributeurs avec des problèmes invalides.

Impacts de rapports de mauvaise qualité sur les mainteneurs

Ce phénomène exacerbe une charge de travail déjà lourde. Beaucoup de mainteneurs sont des bénévoles qui jonglent entre leur travail, leur vie personnelle, et leurs responsabilités dans des projets open source. Traiter des rapports inutiles prend du temps, fatigue émotionnellement et peut entraîner un épuisement professionnel. Seth Larson estime que les rapports de mauvaise qualité doivent être traités comme s'ils étaient malveillants.

À titre d'exemple, Daniel Stenberg a évoqué un rapport de bogue datant du 4 mai 2025. Il suggérait un « nouvel exploit exploitant les cycles de dépendance de flux dans la pile de protocoles HTTP/3 ». La mauvaise gestion des dépendances de flux, lorsqu'un aspect d'un programme attend la sortie d'un autre aspect, peut conduire à l'injection de données malveillantes, à des conditions de course et à des plantages, ainsi qu'à d'autres problèmes.

Le rapport en question suggère que cela pourrait rendre cURL, qui est compatible avec HTTP/3, vulnérable à des exploits pouvant permettre l'exécution de code à distance. Mais comme le souligne le personnel de cURL, le correctif « configuration de serveur malveillant » soumis ne s'appliquait pas aux dernières versions d'un outil Python en question. Interrogé à ce sujet, l'auteur du signalement a répondu d'une manière étrangement prompte.

Il répondait à des questions qui n'avaient pas été posées par l'équipe de cURL et incluait ce qui semble être des instructions de base sur la manière d'utiliser l'outil git pour appliquer un nouveau correctif. L'auteur du signalement n'a pas non plus fourni le nouveau fichier correctif demandé, a cité des fonctions qui n'existent pas dans les bibliothèques sous-jacentes et a suggéré des tactiques de renforcement pour des utilitaires autres que cURL.

L'équipe de cURL a finalement fermé le rapport, mais l'a également rendu public pour servir d'exemple. Alex Rice, cofondateur, directeur technique et responsable de la sécurité des systèmes d'information de HackerOne, a déclaré que les rapports contenant « des vulnérabilités hallucinées, un contenu technique vague ou incorrect, ou d'autres formes de bruit à faible effort » sont traités comme du spam et font l'objet d'une mise en application.

Le problème viendrait des utilisateurs et non de la technologie

Ce phénomène souligne un problème plus général : les projets open source fonctionnent grâce à quelques bénévoles. L’utilisation abusive de l'IA peut nuire à l’écosystème, en gaspillant l'énergie précieuse des personnes qui le maintiennent. Les hallucinations des modèles constituent un problème majeur de l'IA générative auquel les chercheurs n'ont pas encore trouvé de solution. Selon une étude de 2024, il pourrait s'agir d'un problème insoluble.

Dans certains cas, les auteurs des signalements erronés sont des personnes novices qui testent des IA sur du code. Ou pire, elles utilisent les rapports générés par l'IA pour tenter d'obtenir des récompenses financières via des programmes de primes aux bogues sans fournir de véritables contributions.

Il apparaît désormais que le problème vient davantage des personnes que de la technologie. En septembre 2025, le projet cURL a reçu des dizaines de signalements potentiels de Joshua Rogers, un chercheur en sécurité basé en Pologne. Joshua Rogers a identifié divers bogues et vulnérabilités à l'aide de plusieurs outils d'analyse propulsés par l'IA. Ses rapports se sont révélés non seulement valables, mais également beaucoup appréciés des mainteneurs.

Dans un billet publié sur Mastodon, Daniel Stenberg a déclaré : « ce sont vraiment des découvertes impressionnantes ». Dans sa mise à jour sur la liste de diffusion du projet, il a déclaré : « la plupart d'entre eux étaient de petites erreurs et des détails insignifiants dans le style d'un analyseur de code statique ordinaire, mais il s'agissait tout de même d'erreurs qu'il valait mieux corriger. Plusieurs des problèmes détectés étaient des découvertes assez impressionnantes ».

Parmi les vulnérabilités découvertes figurait une lecture hors limites dans Kerberos5 FTP qui n'a pas été considérée comme une faille de sécurité, mais qui a néanmoins été corrigée. Selon Daniel Stenberg, une cinquantaine de corrections de bogues basées sur les rapports de Joshua Rogers avaient été fusionnées.

Il faut néanmoins rester prudent quant à la façon d'utiliser l'IA

Le principal responsable du projet cURL Daniel Stenberg a reconnu la valeur de ces signalements. Les problèmes détectés allaient de petites incohérences à des bogues réels dans le code de la bibliothèque cURL. Toutefois, Daniel Stenberg reste prudent. Il explique que ces nouveaux outils représentent une évolution utile, non pas une révolution. L’IA ne remplace pas les développeurs, mais sert d’assistant capable de repérer des zones de code problématiques.

« Je ne pense pas que cela ait beaucoup changé mon opinion sur l'IA, si ce n'est peut-être prouver qu'il existe d'excellents outils d'analyse de code basés sur l'IA. Cela souligne peut-être aussi à quel point les rapports que nous recevons encore de la part des utilisateurs les plus naïfs sont ridicules », a-t-il écrit.

Joshua Rogers a rédigé un résumé des outils d'IA d'analyse des vulnérabilités qu'il a testés. Il a conclu que ces outils (Almanax, Corgea, ZeroPath, Gecko et Amplify) sont capables de détecter de réelles vulnérabilités dans des codes complexes. « Ce type de systèmes sera probablement la technologie la plus influente, voire la plus intéressante et la plus efficace pour détecter les vulnérabilités dans un avenir proche, du genre de celles que l'on n'avait plus vues depuis 2013 environ, lorsque le fuzzing est redevenu populaire avec afl-fuzz », a-t-il écrit.

L'industrie se tourne vers la recherche de bogues assistée par l'IA

Le projet OSS-Fuzz de Google a déclaré que la recherche de bogues assistée par l'IA est efficace. Mais le message est plus crédible lorsqu'il provient d'un chercheur en sécurité individuel plutôt que d'un fournisseur d'IA disposant d'énormes ressources. Dans le même temps, l'expérience rapports de mauvaise qualité prouve que l'IA est loin d'être prête à travailler de manière autonome. Joshua Rogers a particulièrement fait l'éloge de l'outil ZeroPath.

« En analysant des logiciels open source, il a littéralement trouvé des centaines de vulnérabilités et de bogues réels dans des logiciels très critiques : sudo, libwebm, Next.js, Avahi, hostap, cURL, Squid (pas si critique, mais il a littéralement trouvé plus de 200 bogues réels). Oui, enfin, l'IA a trouvé de vrais bogues dans cURL ! En effet, non seulement ZeroPath a trouvé une multitude de vulnérabilités, mais il s'est également révélé redoutablement efficace pour trouver des bogues normaux, lorsqu'on lui a donné une règle personnalisée pour le faire », a déclaré le chercheur en sécurité.

Malgré tout, ces outils ont leurs limites. Joshua Rogers a déclaré qu'aucun des outils d'IA d'analyse de code n'avait été capable de détecter un bogue de boucle infinie précédemment identifié dans le package npm image-size. Selon lui, cette vulnérabilité n'avait toujours pas été corrigée en septembre 2025, malgré un correctif soumis en avril. Là encore, c'est un problème humain.

Conclusion

Les rapports de bogue de mauvaise qualité générés par l'IA sont devenus un problème pour les mainteneurs de logiciels libres et open source. Ce phénomène met en évidence les défis posés par l'utilisation non encadrée de l'IA dans la détection de vulnérabilités. Selon Daniel Stenberg et d'autres, cela souligne la nécessité d'une approche plus rigoureuse et collaborative pour maintenir la qualité et la sécurité des projets libres et open source.

Toutefois, l’expérience de cURL montre que l’IA peut être efficace lorsqu’elle est utilisée sous supervision humaine. Ce n’est pas l’outil en lui-même qui fait la différence, mais la façon dont il est exploité. Les humains doivent toujours vérifier, filtrer et valider les rapports avant d’agir. Lorsqu'ils sont utilisés par une personne ayant une expérience significative dans le domaine, les outils d'IA peuvent être très utiles, voire surprenants.

Sources : Daniel Stenberg, responsable du projet open source cURL ; Joshua Rogers, chercheur en sécurité

Et vous ?

Quel est votre avis sur le sujet ?
Que vous inspire l'expérience de cURL ?
Que pensez-vous des outils actuels d'IA d'analyse de code ?
Ces outils pourront-ils un jour être déployés sans supervision humaine ?

Voir aussi

Le projet open source cURL interdit les rapports de bogue inutiles générés par l'IA : « nous n'avons toujours pas vu un seul rapport de sécurité valide rédigé avec l'aide de l'IA »

Les mainteneurs de logiciels libres sont noyés dans des rapports de bogues inutiles rédigés par l'IA. « Ces systèmes ne sont pas encore capable de comprendre le code », estime un développeur

L'IA peut écrire du code mais ne parvient pas à le comprendre, selon une étude d'OpenAI. Testés sur des tâches réelles de programmation, les modèles les plus avancés n'ont pu résoudre qu'un quart des défis

[Alex]

Linus Torvalds fustige les rapports de bogues générés par l'IA qui perturbent le développement du noyau Linux avec la version 7.1 RC4, notamment un flot chaotique de rapports en double générés par l'IA

Linus Torvalds met en garde contre le fait que les rapports de bogues générés par l'IA submergent la liste de diffusion sur la sécurité Linux de doublons et de bruit. La liste de diffusion sur la sécurité Linux est désormais « presque totalement ingérable », a averti le responsable principal Linus Torvalds. « Le flot continu de rapports générés par l'IA a rendu la liste de sécurité pratiquement ingérable, avec d'énormes doublons dus au fait que différentes personnes trouvent les mêmes choses avec les mêmes outils », a-t-il déclaré. Torvalds a souligné que ces rapports constituent « un gaspillage de temps totalement inutile », car la plupart des bogues détectés par les outils d’IA sont « par définition, loin d’être secrets », et que les signaler « ne fait qu’aggraver les doublons ».

Le noyau Linux est un noyau libre et open source de type Unix utilisé dans de nombreux systèmes informatiques à travers le monde. Le noyau a été créé par Linus Torvalds en 1991 et a rapidement été adopté comme noyau du système d'exploitation GNU, conçu pour remplacer librement Unix. Depuis la fin des années 1990, il est intégré à de nombreuses distributions de systèmes d'exploitation, dont beaucoup sont appelées Linux. Android, utilisé dans de nombreux appareils mobiles et embarqués, est l'un de ces systèmes d'exploitation basés sur le noyau Linux.

Linus Benedict Torvalds, né le 28 décembre 1969, est un ingénieur logiciel finlandais et américain, créateur et développeur principal du noyau Linux depuis 1991. Il a également créé le système de contrôle de version distribué Git. Torvalds a été l'un des lauréats du Prix Millennium Technology 2012 « en reconnaissance de sa création d'un nouveau système d'exploitation open source pour ordinateurs ayant conduit au noyau Linux largement utilisé ». En 2006, environ 2 % du noyau Linux avait été écrit par Torvalds. Malgré les milliers de personnes qui y ont contribué, son pourcentage reste l'un des plus élevés. Cependant, il a déclaré en 2012 que sa contribution personnelle consistait désormais principalement à fusionner du code écrit par d'autres, avec peu de programmation. Il conserve la plus haute autorité pour décider quel nouveau code est intégré au noyau Linux standard.

Les mainteneurs jouent un rôle essentiel dans l'univers de l'open source. Ces bénévoles consacrent leur temps et leur expertise à maintenir des projets utilisés par des millions de personnes à travers le monde. Pourtant, un phénomène inquiétant perturbe leur travail : une multiplication des rapports de bogues de mauvaise qualité générés par des intelligences artificielles (IA). Les soumissions de vulnérabilités logicielles générées par des modèles d'IA ont inauguré une « nouvelle ère de rapports de sécurité bâclés pour l'open source » et les développeurs qui maintiennent ces projets souhaiteraient que les chasseurs de bogues s'appuient moins sur les résultats produits par les assistants d'apprentissage automatique.

Seth Larson, développeur de sécurité en résidence à la Python Software Foundation, avait notamment exhorté les personnes qui signalent des bogues à ne pas utiliser de systèmes d'IA pour la chasse aux bogues. En 2024, il a déclaré : « Récemment, j'ai remarqué une augmentation des rapports de sécurité de qualité extrêmement médiocre, spammés et hallucinés par LLM dans les projets open source. Ces rapports semblent à première vue potentiellement légitimes et nécessitent donc du temps pour être réfutés ». Larson a estimé que les rapports de mauvaise qualité doivent être traités comme s'ils étaient malveillants.

Récemment, Linus Torvalds a fait des déclarations similaires. En effet, la liste de diffusion sur la sécurité Linux est désormais « presque totalement ingérable », depuis que les chercheurs ont commencé à utiliser l’IA pour l’inonder de rapports inutiles, a averti le responsable principal Linus Torvalds. Après avoir qualifié la dernière version candidate de « relativement normale » dans son dernier billet hebdomadaire sur l’état du noyau, abordant des sujets tels que les pilotes, la mise en réseau, le noyau central et bien d’autres, Torvalds a souligné que « certaines mises à jour de la documentation mériteraient d’être mises en avant ».

« Le flot continu de rapports générés par l'IA a rendu la liste de sécurité pratiquement ingérable, avec d'énormes doublons dus au fait que différentes personnes trouvent les mêmes choses avec les mêmes outils », a-t-il déclaré. « Les gens passent tout leur temps à simplement transférer des informations aux bonnes personnes ou à dire « cela a déjà été corrigé il y a une semaine/un mois » et à renvoyer vers la discussion publique ». Torvalds a souligné que ces rapports constituent « un gaspillage de temps totalement inutile », car la plupart des bogues détectés par les outils d’IA sont « par définition, loin d’être secrets », et que les signaler « ne fait qu’aggraver les doublons ».

Au-delà de ses critiques, Torvalds a également donné quelques conseils concrets, invitant les chercheurs à utiliser l’IA « d’une manière productive et qui améliore l’expérience » : « La documentation est peut-être un peu moins directe que moi, mais c’est l’essentiel », a-t-il conclu. « Si vous voulez vraiment apporter une valeur ajoutée, lisez la documentation, créez aussi un correctif, et ajoutez une réelle valeur *en plus* de ce que l’IA a fait. Ne soyez pas le genre de personne qui passe en coup de vent pour « envoyer un rapport au hasard sans véritable compréhension ». »

Cette déclaration rappelle un rapport de CodeRabbit, qui a révélé que le code généré par l'IA présente nettement plus de défauts que le code écrit par des humains dans les principales catégories de qualité logicielle. Le rapport a révélé que les pull requests générées par l'IA contiennent en moyenne environ 1,7 fois plus de problèmes que celles écrites uniquement par des humains. Il a également identifié des taux plus élevés de défauts critiques et majeurs dans le code impliquant des outils d'IA.

Voici la déclaration de Linus Torvalds :

Vous connaissez tous la chanson désormais : une nouvelle semaine, une nouvelle version candidate.

La situation semble rester relativement normale (où « normale » désigne la « nouvelle normalité », avec tout de même pas mal de changements). Les pilotes représentent environ la moitié du patch, les pilotes GPU occupant comme d’habitude la première place. Mais on trouve un peu de tout dans le domaine des pilotes.

Le reste concerne principalement les réseaux, le noyau central, les systèmes de fichiers et les mises à jour des architectures.

Certaines mises à jour de la documentation méritent d'être soulignées : le flot continu de rapports AI a rendu la liste de sécurité pratiquement ingérable, avec d'énormes doublons dus au fait que différentes personnes trouvent les mêmes choses avec les mêmes outils. Les gens passent tout leur temps à simplement transférer les informations aux bonnes personnes ou à dire « ça a déjà été corrigé il y a une semaine/un mois » en renvoyant vers la discussion publique.

Tout cela n'est qu'une agitation totalement inutile, et nous affirmons clairement que les bogues détectés par l'IA ne sont, par définition, pas secrets, et que les traiter sur une liste privée est une perte de temps pour toutes les personnes concernées — et ne fait qu'aggraver ces doublons, car les rapporteurs ne peuvent même pas voir les rapports des uns et des autres.

Les outils d'IA sont formidables, mais seulement s'ils aident réellement, plutôt que de causer des tracas inutiles et un travail fictif sans intérêt. N'hésitez pas à les utiliser, mais faites-le de manière productive et de façon à améliorer l'expérience.

La documentation est peut-être un peu moins directe que moi, mais c'est là l' essentiel. Donc, pour que ce soit bien clair : si vous avez trouvé un bug à l'aide d'outils d'IA, il y a de fortes chances que quelqu'un d'autre l'ait trouvé aussi. Si vous voulez vraiment apporter une valeur ajoutée, lisez la documentation, créez un correctif vous aussi, et ajoutez une réelle valeur *en plus* de ce que l'IA a fait. Ne soyez pas le genre de personne qui « envoie un rapport au hasard sans vraiment comprendre ». D'accord ?

Linus

Source : Message de Linus Torvalds

Et vous ?

Pensez-vous que cette déclaration est crédible ou pertinente ?
Quel est votre avis sur le sujet ?

Voir aussi :

Linus Torvalds refuse de transformer la documentation du kernel en champ de bataille idéologique « anti-IA » : arrêtez de faire toute une histoire de « l'IA slop » dans la documentation du noyau

Un mainteneur propose d'ajouter un « kill switch » au noyau Linux après la divulgation récente de plusieurs vulnérabilités critiques, mais son impact sur la stabilité du système suscite un débat

Linux fixe les règles en matière de code généré par IA : Oui à Copilot, les humains endossent les erreurs. Après des mois de débats acharnés, Torvalds et les mainteneurs parviennent à un accord.

[Patrick Ruiz]

« Rust sauvera Linux de l’IA », affirme Greg Kroah-Hartman dans le cadre d’une critique de l’usage de l’intelligence artificielle pour trouver les bogues au sein du code du noyau écrit en langage C

Greg Kroah-Hartman, responsable de la maintenance du noyau stable de Linux, affirme que Rust peut aider Linux à faire face à un afflux de failles de sécurité détectées par l'IA (notamment Dirty Frag, Copy Fail et Fragnesia) en prévenant les erreurs courantes en C liées à la gestion de la mémoire, au verrouillage, à la gestion des erreurs et aux données non fiables dès la phase de compilation, plutôt que lors de la révision par les mainteneurs. Sa sortie est de nature à donner un coup de neuf au débat sur la comparaison entre les langages Rust et C en matière de programmation système.

Ce n'est « pas une solution miracle » et cela ne signifie pas qu'il faille réécrire l'intégralité du noyau, mais Greg Kroah-Hartman est d’avis que les nouveaux pilotes et sous-systèmes doivent s’appuyer sur Rust au fur et à mesure de l’évolution du noyau.

Kroah-Hartman illustre son positionnement à l'aide de véritables bogues en C présents dans le noyau, notamment un bogue Bluetooth vieux de 15 ans qui déréférençait un pointeur sans le vérifier et un bogue Xen d’oubli de déverrouillage dans une branche d'exception. « La majorité des bogues dans le noyau sont de ces petits détails insignifiants », explique-t-il. « Les conditions d'erreur ne sont pas vérifiées, les verrous ne sont pas oubliés, les mémoires non libérées fuient et les vulnérabilités s'accumulent au fil du temps. Elles provoquent le plantage du noyau. C'est ce à quoi nous sommes confrontés avec le C. C'est pourquoi nous ne l'aimons pas. »

Kroah-Hartman fait valoir que « la plus grande beauté de Rust » réside dans le fait de détecter ces erreurs lors de la compilation plutôt que lors de la révision. Par exemple, en matière de verrouillage, il a mis en avant les abstractions de verrouillage de Rust dans le noyau : « La seule façon d’accéder aux pointeurs internes des structures est d’acquérir ce verrou, puis de le libérer automatiquement. Le compilateur s’en charge, c’est sécurisé, le verrouillage s’effectue, tout va bien. Il est tout simplement impossible d’écrire du code pour accéder à ces valeurs sans acquérir le verrou. Le compilateur ne vous le permettra pas. »

Ces propriétés éliminent directement une grande partie des bogues qu’il constate : « Cela va nous éviter deux choses. Premièrement, 60 % des bogues du noyau disparaissent d’un coup. Kroah-Hartman est d’avis que même si Rust disparaissait demain, il a déjà contraint le noyau à nettoyer le code C et les interfaces.

Brian Kernighan pour sa part critique vivement les performances du langage Rust

« Pensez-vous que Rust ait un quelconque intérêt à remplacer C ? Ou s'agit-il simplement d'un énorme battage médiatique qui finira par s'essouffler ? », a demandé un membre du public. Dans un monde qui évolue depuis des années vers des langages plus sûrs pour la mémoire, la réponse d'un fervent défenseur du langage de programmation C depuis plus d'un demi-siècle promettait d'être tout simplement emblématique. Il s'est montré très très critique.

Brian Kernighan a trouvé son expérience avec Rust « pénible ». Selon lui, les mécanismes imposés par Rust pour garantir la sécurité mémoire sont trop lourds, surtout dans un programme où la gestion de la mémoire n’était pas un problème majeur. Il décrit son unique essai comme « une douleur », et juge l’écosystème du langage — avec ses crates, sa complexité et la lenteur de la compilation — comme « incompréhensiblement vaste et lent ».

« Ohhh, Rust », a déclaré Brian Kernighan, sous les rires du public. « Je n'ai écrit qu'un seul programme en Rust, vous devez donc prendre tout cela avec beaucoup de recul. Et j'ai trouvé cela pénible. Je n'arrivais tout simplement pas à comprendre les mécanismes nécessaires pour assurer la sécurité de la mémoire, dans un programme où la mémoire n'était même pas un problème ! ». Sa plus grande critique semble concerner ses performances de Rust.

« Et le compilateur était lent, le code qui en ressortait était lent... », a-t-il déclaré. « Quand j'ai essayé de comprendre ce qui se passait, le langage avait changé depuis la dernière fois que quelqu'un avait publié une description ! Il m'a donc fallu plusieurs jours pour écrire un programme qui, dans d'autres langages, aurait pris peut-être cinq minutes... »

Le 15 mai 2025, le compte Twitter officiel du projet FFmpeg a publié un message acerbe à l'encontre de Rust qui dit : « [Rust] est tellement bon que l'on peut être payé 20 000 $ pour le rendre aussi rapide que C ». Cette remarque visait l'initiative de Prossimo, qui a proposé une prime de 20 000 $ à quiconque parviendrait à rendre son décodeur AV1, rav1d, aussi rapide que dav1d, une implémentation en C largement reconnue pour sa rapidité.

Cette déclaration a ravivé le débat sur les compromis entre sécurité mémoire, performance et coût dans le développement de systèmes critiques. Il s'agit d'un débat de longue date dans la communauté des développeurs. Certains chérissent les performances brutes, tandis que d'autres préfèrent la sécurité.

Certains intervenants pensent que le choix de Rust est une erreur et que C++ moderne est une meilleure alternative

« Maintenant, "pourquoi pas Rust" ? Tout d'abord, Rust utilise une syntaxe différente (souvent, à mon avis, gratuitement), et non seulement tous les développeurs du noyau devraient se familiariser intimement avec la syntaxe afin d'obtenir le même type de "feeling" que nous avons pour le C, mais convertir du code C en Rust n'est pas quelque chose qui ne peut être fait par les développeurs du noyau qu'au coup par coup, alors qu'avec quelques nettoyages le code C existant peut être compilé en C++.

Cependant, je ne suis pas d'accord avec certaines des conclusions de David. en fait, je crois que David est inutilement pessimiste, du moins en ce qui concerne le C++ moderne.

Notez que personne de sain d'esprit ne s'attend à utiliser toutes les fonctionnalités de C++. Tout comme nous avons le "kernel C" (actuellement un sous-ensemble de C11 avec un avec un ensemble relativement large d'extensions spécifiques au compilateur), nous aurions le "noyau C++", que je suggère d'être un sous-ensemble strictement défini de de C++20, combiné à un ensemble similaire d'extensions de compilateur). Je me rends compte que que la prise en charge du C++20 par les compilateurs est encore très récente pour des raisons évidentes, de sorte qu'au moins une partie de ce qui précède est tournée vers l'avenir », souligne le développeur Linux – Peter anvin.

Jiri Slaby de SUSE Lans s'est prononcé en faveur de cette initiative C++ pour le noyau Linux. David Howells de Red Hat s'est également prononcé en faveur de cette approche.

Et vous ?

Le langage C a-t-il réellement besoin d'un remplaçant dans la filière de la programmation système ?
Partagez-vous les avis selon lesquels le choix de Rust comme langage de développement du noyau est une erreur ? Voyez-vous le C++ moderne comme meilleure solution aux questions d’évolution du noyau ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

[Artaeus]

Ce projet, c'est réinventer la roue (mais en version bien plus lente) ...

La manière dont cette priorité de "passer en Rust" est poussée m'interroge beaucoup sur des conflits d'intérêt et des non-dit en coulisse.

[imperio]

Ce projet, c'est réinventer la roue (mais en version bien plus lente) ...

La manière dont cette priorité de "passer en Rust" est poussée m'interroge beaucoup sur des conflits d'intérêt et des non-dit en coulisse.

Faire des économies d'argent sur le long-terme en enlevant toute une catégorie de bugs et attirer des contributeurs plus jeunes sur le noyau pour assurer sa pérennité dans le temps.

C'est pas comme si Rust était testé dans le kernel depuis plusieurs années pour voir si ça valait le coup et leur convenait après tout... Et le plus beau : tous ces débats sont publics. Faut arrêter de chercher des complots à un moment...

[Uther]

La priorité n'est pas de passer en Rust, Greg Kroah-Hartman est clair là dessus dans la conférence. Il dit que Rust est a préférer pour les nouveaux driver / sous-systèmes, mais il n'est pas question de demander aux mainteneurs de recoder ce qui existe déjà en Rust. Si un module est remplacé, comme l'Android Binder qu'il donne en exemple, c'est que c'est une volonté du mainteneur, en l’occurrence Google.

[Artaeus]

Faire des économies d'argent sur le long-terme en enlevant toute une catégorie de bugs et attirer des contributeurs plus jeunes sur le noyau pour assurer sa pérennité dans le temps.

C'est pas comme si Rust était testé dans le kernel depuis plusieurs années pour voir si ça valait le coup et leur convenait après tout... Et le plus beau : tous ces débats sont publics. Faut arrêter de chercher des complots à un moment...

Dois-je faire la blague du 1 Avril sur l’implémentation Rust dans ffmpeg ?

Avec l'explosion des couts matériels, la priorité doit-être la rapidité (comme ça a toujours été le cas). Les bons dev, jeunes ou anciens, sécurisent leur code.

[fr1man]

@Artaeus
Parce que vous croyez que seuls les mauvais développeurs introduisent des bugs ?
C'est un peu simpliste comme raisonnement.

[fdecode]

Les bons dev, jeunes ou anciens, sécurisent leur code.

Maladroit! Vous êtes en train de sous-entendre que les concepteurs des applis qu'on utilise tout le temps et qui présentent régulièrement des bugs sont des grosses brêles...

Avec l'explosion des couts matériels, la priorité doit-être la rapidité (comme ça a toujours été le cas).

Ça tombe bien! La sémantique du langage Rust, et notamment la sémantique de prêt, associée aux capacités d’optimisation du compilateur de Rust permettent de très bonnes optimisation du code. Par exemple, la sémantique de prêt offre un contrôle de l'aliasing de la mémoire probablement plus précis qu'un mot clef comme 'restrict' en C. On pourrait aussi évoquer les facilités à paralléliser le code...

[calvaire]

je n'ai rien contre rust, mais je ne comprends pas ce forcing.
J'ai l'impression d'y voir une secte qui veut absolument imposer ce langage et rapidement en plus.

Dans ma boite nous faisons des projets en C/C++ sans ressentir le besoin d'aller sur du rust.

[Mingolito]

Il y a un conflit de génération, les anciens codeur C++ de l'équipe seront bientôt séniles ou morts, et les jeunes ne veulent pas coder en C++ c'est trop compliqué, mais en Rust peut être. Donc l'idée est de remplacer l'équipe C++ mourante par une équipe plus jeune, sur Rust.
Il faut quand même reconnaitre que le code Rust sera plus facile à lire et induira moins de risques de vulnérabilités que le C++. Google est déjà en train de faire le pas avec des résultats probants :

Google a adopté Rust pour des raisons de sécurité et a constaté une réduction de 1 000 fois des vulnérabilités liées à la sécurité de la mémoire

« Les équipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++ »

[fdecode]

je ne comprends pas ce forcing.

Parlons concrètement! Quelqu'un vous force-t-il à programmer en Rust?

[fdecode]

Il y a un conflit de génération, les anciens codeur C++ de l'équipe seront bientôt séniles ou morts, et les jeunes ne veulent pas coder en C++ c'est trop compliqué, mais en Rust peut être. Donc l'idée est de remplacer l'équipe C++ mourante par une équipe plus jeune, sur Rust.
Il faut quand même reconnaitre que le code Rust sera plus facile à lire et induira moins de risques de vulnérabilités que le C++. Google est déjà en train de faire le pas avec des résultats probants :

Google a adopté Rust pour des raisons de sécurité et a constaté une réduction de 1 000 fois des vulnérabilités liées à la sécurité de la mémoire

« Les équipes Rust chez Google sont deux fois plus productives que celles qui se servent de C++ »

Le langage développé par Google, c'est surtout Go. Mais il est vrai que Google met particulièrement en avant Rust, le langage qui a été créé par Mozilla notamment pour d'anciens projets expérimentaux comme servo.

Mais je me réfère plutôt à la liste des financeurs de la fondation Rust, pour mesurer l'adoption progressive du langage.

https://rustfoundation.org/members/

J'avais noté précédemment l'arrivée d'arm comme financeur Platinum du langage, mais je note aussi que Canonical, le commanditaire de l'OS Ubuntu, est désormais financeur Gold.

Et non, il n’y a pas de complot contre les langages C/C++ : il s’agit simplement d’une montée d’intérêt progressive, venant de différents acteurs indépendants, sans implication particulière au départ dans ce projet.

[UneMouchePasse]

je n'ai rien contre rust, mais je ne comprends pas ce forcing.
J'ai l'impression d'y voir une secte qui veut absolument imposer ce langage et rapidement en plus.

Dans ma boite nous faisons des projets en C/C++ sans ressentir le besoin d'aller sur du rust.

Chacun voit midi à sa porte, perso la secte C\C++ bloquée dans les années 2000 je la trouve encore bien présente. Enfin elle est bientôt à la retraite.

[fdecode]

Chacun voit midi à sa porte, perso la secte C\C++ bloquée dans les années 2000 je la trouve encore bien présente. Enfin elle est bientôt à la retraite.

Je suis vieux et j'aime bien Rust! On n'est pas dans une guerre générationnelle, quand même!