Money Tree Browser qui attribue les primes de bug de Chromium

Présentation de Chromium Money Tree Browser

• Chromium Money Tree Browser est un site web qui relie les récompenses du Chrome VRP (programme de primes aux bugs) aux modifications apportées à des fichiers précis.
• Le site a été réalisé de manière très simple, et il vaut mieux ne pas trop en attendre en matière d’expérience utilisateur ou de précision des données.
• Les primes sont réparties par fichier : par exemple, si la correction d’un bug d’une valeur de 1 000 $ a nécessité la modification de 5 fichiers, chaque fichier se voit attribuer 200 $.
• Les données se basent sur les informations disponibles jusqu’au début novembre 2023.

L’avis de GN⁺

• Chromium Money Tree Browser est un outil intéressant qui montre visuellement aux développeurs et aux chercheurs en sécurité quels fichiers ont été modifiés dans le cadre du programme de primes aux bugs de Chrome, ainsi que la manière dont les récompenses associées ont été réparties.
• Le site apporte un éclairage sur la façon dont les récompenses liées aux corrections de bugs sont calculées, et peut aider à partager des informations utiles au sein de la communauté de la sécurité.
• Même s’il faut modérer ses attentes concernant l’expérience utilisateur ou l’exactitude des données, ce site peut contribuer à mieux faire connaître les vulnérabilités de sécurité dans les projets open source et à inciter les développeurs à accorder davantage d’importance à la sécurité.

[GN⁺]

Avis Hacker News

• Intérêt pour quelque chose de similaire à une fonctionnalité qu’un développeur voulait construire depuis longtemps

  • Réflexion sur l’utilité d’une méthode permettant de calculer la probabilité qu’un changement donné provoque un problème, à partir des modifications survenues dans le passé dans un fichier ou dans une partie précise d’un fichier.
  • Attribuer un score de risque à chaque changement, puis relier ce score à une PR (Pull Request) afin de signaler aux relecteurs de code les parties nécessitant une attention supplémentaire, et s’en servir comme indicateur pour mettre en évidence les changements risqués au moment du déploiement.
  • Il est difficile de suivre la même portion de code lorsqu’elle se déplace vers le haut ou vers le bas à cause d’insertions/suppressions. Un algorithme basé simplement sur les numéros de ligne peut poser problème.
  • Cela laisse penser qu’un travail effectué au niveau du fichier pourrait déjà être suffisamment utile.

• Remarque sur l’absence de certaines corrections dans des bibliothèques tierces spécifiques

  • Il semble que certaines corrections effectuées dans des bibliothèques tierces (par ex. ffmpeg) manquent. Ces corrections sont souvent traitées d’abord en amont, ce qui peut rendre leur suivi difficile.

• Réflexion, en examinant de nombreux bugs de l’UI de Chrome, sur les problèmes de use-after-free dans des données où les performances de la gestion manuelle de la mémoire n’ont pas d’importance

  • Observation de problèmes de use-after-free survenant dans du code comme le cycle de vie de la boîte de dialogue « sélection de fichier », alors même que les performances de la gestion manuelle de la mémoire n’y sont pas critiques.
  • Cela suggère que, dans ce type de code, il vaudrait peut-être mieux utiliser systématiquement des pointeurs plus intelligents et plus lents.
  • Mention du fait que des types comme raw_ptr<T> semblent avoir été conçus pour aider, et qu’ils ont peut-être effectivement réussi à prévenir le crash survenu en [2].
  • Regret de l’absence, au sein du projet, d’un moyen de passer d’un dialecte à l’autre entre le code sensible aux performances et le code où celles-ci sont beaucoup moins déterminantes.
  • Réflexion sur la possibilité qu’il soit presque utile de mélanger deux langages différents afin de distinguer clairement les parties sensibles aux performances et celles riches en états asynchrones, donc plus susceptibles de mal tourner.

• Éloges sur l’efficacité de la visualisation et remarque sur l’utilisation du CPU

  • Visualisation très propre, avec la remarque que l’utilisation du CPU est un peu élevée lorsqu’on développe les zones.
  • Attente que l’équipe Chrome utilise probablement déjà un outil similaire en interne, et avis selon lequel cela serait utile pour comprendre la surface d’attaque.

• Éloges sur l’idée et l’exécution, et question sur les données brutes

  • Compliment sur une idée excellente et une exécution réussie.
  • Mention de l’accessibilité éventuelle des données brutes et de l’intérêt d’essayer un sunburst ou une tree map.

• Suggestion de ne pas inclure certains types de fichiers

  • Remarque détaillée suggérant de ne pas inclure les fichiers DEPS, AUTHORS et BUILD.gn.

• Suggestion d’appliquer une pondération selon le nombre de lignes de code modifiées

  • Avis selon lequel il serait intéressant de pondérer l’« argent » attribué aux bugs selon le nombre de lignes de code modifiées.
  • Proposition selon laquelle, si 10 lignes du fichier A et 1 ligne du fichier B ont été modifiées, le fichier B recevrait 1/11 de l’« argent », puisque le fichier A représenterait l’essentiel du bug.

• Demande d’une fonctionnalité affichant la récompense moyenne par fichier

  • Demande d’une fonctionnalité affichant, pour chaque nœud, la récompense moyenne par fichier.

• Idée d’un affichage des montants normalisés selon le nombre de lignes de code

  • Suggestion d’une version affichant les montants normalisés en fonction du nombre de lignes de code.

• Éloges sur les insights visuels concernant les zones où concentrer les efforts

  • Appréciation du fait que cela fournisse des insights visuels très utiles sur les domaines où concentrer les efforts.