Bitcoin Core a révisé sa politique de divulgation des vulnérabilités, supprimant la période d'embargo basée sur la gravité pour les bugs faciles à découvrir — y compris les failles qui peuvent être identifiées par une simple requête à un modèle de langage. Le développeur Antoine Poinsot a intégré la modification dans la politique de sécurité du projet le 22 octobre.

Cette mise à jour est une règle de divulgation, et non le signalement d'un nouvel exploit ; elle ne dit rien de la cryptographie de Bitcoin ni de la sécurité des clés privées des utilisateurs.

Pourquoi l'IA a affaibli l'embargo

Les développeurs ont écrit avoir récemment constaté davantage de signalements de vulnérabilités faciles à trouver, ou redécouvertes. Ils l'attribuent en grande partie aux modèles de langage, qui abaissent la barrière pour repérer certaines classes de bugs et peuvent également identifier des correctifs discrets — des correctifs de sécurité fusionnés dans le code sans être étiquetés comme tels.

Ce second point nuit à l'objectif même de l'embargo, la période pendant laquelle les mainteneurs retiennent les détails d'une faille signalée pendant la préparation d'une version corrigée. Bitcoin Core est open source, si bien qu'un correctif est visible dans le code public bien avant la publication de ses détails. Si un modèle peut reconnaître une modification comme un correctif de sécurité, le silence fait peu pour dissimuler le bug aux attaquants tout en retardant la publication d'une version corrigée pour les utilisateurs.

« La période d'embargo apporte peu mais retarde la disponibilité d'une version corrigée », ont écrit les développeurs.

Les embargos prolongés ont également déterminé où les correctifs étaient déployés. Les développeurs ont noté que leur approche signifiait généralement que les correctifs de sécurité ne pouvaient pas être rétroportés — reportés vers des versions plus anciennes encore prises en charge — et n'atteignaient les utilisateurs qu'avec la prochaine version majeure.

Comment la nouvelle règle modifie le calendrier

Les délais actuels, décrits sur la page des avis de sécurité du projet, montrent à quel point cette attente peut être longue. Les développeurs décident de la classification lors de l'examen d'un signalement.

La nouvelle règle devrait cou les bugs pouvant être découverts avec un minimum d'effort, par exemple via une simple requête à un modèle de langage, sans toutefois se limiter aux découvertes liées à l'IA. Pour ces bugs, l'embargo basé sur la gravité ne s'applique plus, et les détails peuvent être publiés en même temps que la version corrigée plutôt qu'après une période d'attente.

Quels nœuds reçoivent le correctif

La politique de maintenance de Bitcoin Core couvre les trois dernières versions majeures. Lorsqu'une nouvelle version est publiée, la plus ancienne arrive en fin de vie et ne reçoit généralement plus de correctifs de sécurité.

Les nœuds exécutant encore la version 28.x ou antérieure ne recevront généralement pas ces correctifs. Le projet vise une version majeure tous les six à sept mois, et la prochaine, la 32.0, sortira la 29.x de la fenêtre de maintenance. Bitcoin Core recommande d'exécuter la dernière version de maintenance de la version majeure la plus récente vers laquelle un opérateur peut migrer, et sa page de téléchargement explique comment vérifier les sommes de contrôle et les signatures des versions.

Le rétroportage dépend aussi des personnes. La page de cycle de vie du projet indique que le seuil pour rétroporter une modification augmente à mesure qu'une version vieillit, et qu'il n'y a pas toujours assez de bénévoles pour s'en charger. La capacité de maintenance a également influencé d'autres décisions, comme l'a montré le précédent débat sur le soutien de Bitcoin Core au réseau de confidentialité CJDNS.

Le compromis, et ce qu'il faut surveiller

Les développeurs présentent chaque politique de sécurité comme un équilibre entre la transparence, qui aide les attaquants comme les défenseurs, et le temps laissé aux utilisateurs pour mettre à jour — ce que la culture de mise à jour lente de Bitcoin Core rend plus difficile. La publication d'un avis en même temps que les versions corrigées signifie que les détails deviennent publics alors que certains nœuds exécutent encore des logiciels non corrigés. Pour les bugs que des attaquants pourraient découvrir par eux-mêmes, les développeurs jugent qu'un correctif rapide importe plus que le silence sur les détails.

Le premier avis de sécurité publié sous la nouvelle règle montrera la rapidité avec laquelle les versions ponctuelles — mises à jour mineures au sein d'une version majeure — atteignent en pratique les trois versions maintenues. Parallèlement, la publication de la 32.0 réduira l'ensemble des nœuds pouvant les recevoir.

Cet article est fourni à titre informatif uniquement et ne constitue pas un conseil financier ou d'investissement. Les opérateurs de nœuds doivent suivre les notes de version officielles de Bitcoin Core et les instructions de vérification.

Source : Coindoo