• # traduction et résumé auto

    Posté par  . Évalué à -10.

    je ne sais pas bien ce que ca vaut, mais ca semble marcher, dans l'ensemble.

    Le blog de Daniel Stenberg, auteur du célèbre outil curl, critique la façon dont la base de données des CVE (Common Vulnerabilities and Exposures) est gérée. Il prend l'exemple de la CVE-2020-19909, une vulnérabilité critique dans l'outil curl qui a été découverte en 2020.

    Stenberg estime que cette vulnérabilité est un exemple de tout ce qui ne va pas avec les CVE. Tout d'abord, la vulnérabilité a été découverte par un chercheur indépendant, mais elle a mis plusieurs mois à être attribuée à un correctif. Pendant ce temps, les utilisateurs de curl étaient vulnérables à une attaque.

    Deuxièmement, la CVE-2020-19909 a été attribuée à une version spécifique de curl, mais elle existait également dans des versions antérieures. Cela a rendu difficile pour les utilisateurs de déterminer si leur installation était vulnérable.

    Enfin, Stenberg critique la façon dont la CVE-2020-19909 a été documentée. La description de la vulnérabilité est longue et complexe, ce qui la rend difficile à comprendre pour les utilisateurs non experts.

    Stenberg propose plusieurs solutions pour améliorer la gestion des CVE. Il suggère notamment de réduire le temps nécessaire pour l'attribution d'une CVE, d'étendre la documentation des vulnérabilités et de rendre le processus d'attribution plus transparent.

    Voici un résumé des principales critiques de Stenberg :

    • Les CVE ne sont pas toujours attribuées rapidement, ce qui laisse les utilisateurs vulnérables pendant un certain temps.
    • Les CVE ne sont pas toujours documentées de manière claire et concise, ce qui rend difficile pour les utilisateurs de comprendre la nature de la vulnérabilité.
    • Le processus d'attribution des CVE est opaque et ne donne pas toujours une image claire de la nature de la vulnérabilité.

    Stenberg espère que ses critiques contribueront à améliorer la gestion des CVE et à protéger les utilisateurs contre les vulnérabilités de sécurité.

    Cordialement,
    Bard

    • [^] # Cette traduction et résumé auto montre tout ce qui ne va pas avec les modèles de langues

      Posté par  . Évalué à 10.

      je ne sais pas bien ce que ca vaut, mais ca semble marcher, dans l'ensemble.

      Aïe aïe aïe. Désolé mais je vais être un peu rude. Ce n'est pas du tout contre toi, c'était une bonne idée de mettre un résumé en français. Merci pour la démarche mais du coup il y a besoin de rectifier le tir. Je n'ai malheureusement pas le temps juste maintenant de faire une traduction propre et compréhensible, j'en propose une à l'arrache à la fin de mon commentaire. Je suggère de ne pas poster des textes générés par des IA à l'avenir (sans beaucoup de vérifications), elles bullshittent, ne sont pas fiables et c'en est un exemple flagrant.


      J'ai lu ce résumé auto et j'ai eu beaucoup de mal à le comprendre. Je suis allé voir l'article initial qui est lui clair comme de l'eau de roche (j'aime beaucoup l'écriture de Daniel). En revenant sur ce texte, je me rend compte que tout est faux, en plus d'être difficilement compréhensible.

      Par exemple :

      Il prend l'exemple de la CVE-2020-19909,

      Non. Il vient d'apprendre son existence, et c'est le cœur du sujet de l'article

      une vulnérabilité critique dans l'outil curl

      Non. L'article explique bien que justement, ce n'est pas une vulnérabilité, ni une critique

      qui a été découverte en 2020.

      Non. Elle vient d'être rapportée, et il se demande justement pourquoi elle a été attribuée avec ce numéro contenant 2020. De son côté, quelqu'un lui avait déjà soumis le problème

      La description de la vulnérabilité est longue et complexe, ce qui la rend difficile à comprendre pour les utilisateurs non experts.

      Non. Elle fait 100 caractères, 15 mots. On ne peut plus concis. Elle est incompréhensible par des utilisateurs non experts mais Daniel ne parle pas du tout de ça parce que ce n'est pas le problème.

      Stenberg propose plusieurs solutions pour améliorer la gestion des CVE. Il suggère notamment de réduire le temps nécessaire pour l'attribution d'une CVE, d'étendre la documentation des vulnérabilités et de rendre le processus d'attribution plus transparent.

      Non, rien de tout ça.

      Voici un résumé des principales critiques de Stenberg :

      Rien des deux premiers points qui suit n'est vrai. Le 3 ème, vaguement.

      Stenberg espère que ses critiques contribueront à améliorer la gestion des CVE

      Il critique en particulier NVD, sont trop grand pouvoir dans l'attribution des numéros CVEs et son incompétence.

      et à protéger les utilisateurs contre les vulnérabilités de sécurité.

      Pas du tout. Ce n'est pas le sujet.

      Bref, si je comprends bien, on a affaire à Bard, le LLM de Google. J'espère pour eux que l'outil qu'ils proposent depuis quelque jours pour résumer les page web s'en sort mieux que ça.


      Grosso modo, NVD (National Vulnerability Database, une agence américaine déjà critiquée par Daniel par le passé) a attribué une CVE avec un niveau de sévérité quasi maximale (9,8 / 10) il y a quelques jours à un problème mineur sans implication sur la sécurité dans curl corrigé en 2019. On ne sait pas d'où ça sort, pourquoi le numéro de cette CVE contient 2020, pourquoi ce niveau sévérité, mais du coup la CVE est là et plein d'outils automatisés vont récupérer cette CVE et transmettre la fausse information. Il va objecter, et Ubuntu a déjà pris la peine d'affirmer dans leur suivi de sécurité qu'il n'y avait pas de problème et qu'ils étaient non affectés.

  • # la suite

    Posté par  (site web personnel) . Évalué à 3.

  • # Un journal plus détaillé sur ce sujet

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.