Bitcoin Core va divulguer plus rapidement certaines failles : les opérateurs de nœuds pourront-ils mettre à jour à temps ?

Bitcoin Core a modifié sa politique de divulgation de sécurité après que les développeurs ont découvert que certaines vulnérabilités peuvent être redécouvertes avec un effort minimal, y compris par un simple prompt adressé à un modèle d'IA.

La mise à jour de la politique du 22 octobre du projet crée une voie plus rapide pour ces bogues. Les mainteneurs prévoient de publier une version corrective pour chaque version majeure prise en charge dès que possible et de publier un avis de sécurité en parallèle des correctifs. Les autres vulnérabilités conservent le calendrier de divulgation existant. Aucune nouvelle faille particulière n'a été annoncée avec le changement de politique, et un rapport généré par IA n'est pas automatiquement une véritable vulnérabilité. Le changement concerne le délai entre une découverte vérifiée, une version corrigée et les détails publics.

Les nœuds Bitcoin valident localement les blocs et les transactions, et les plateformes d'échange, les dépositaires et d'autres services bâtissent leurs opérations autour d'eux. Une version peut rendre le logiciel corrigé disponible sur les versions prises en charge, mais les opérateurs de ces systèmes décident quand l'installer. Bitcoin Core ne se met pas à jour automatiquement sur chaque machine. La divulgation publique peut aider les gens à identifier un problème et à installer le correctif, tout en donnant à un attaquant des informations qu'un nœud non corrigé pourrait encore révéler par son comportement réseau.

La nouvelle politique sépare la découverte de la gravité

Bitcoin Core classait déjà les vulnérabilités comme critiques, élevées, moyennes ou faibles selon leurs effets et la manière dont elles pouvaient être exploitées. Un plantage déclenché à distance dans les paramètres par défaut peut être de gravité élevée ; une faille qui nécessite une configuration non standard ou cause une perturbation limitée peut être classée plus bas. La politique d'avis de sécurité révisée ajoute une question distincte sur la facilité avec laquelle quelqu'un pourrait trouver le problème. Son exemple est un simple prompt adressé à un grand modèle de langage, mais la catégorie ne se limite pas aux failles trouvées à l'aide de l'IA.

La distinction évite une mauvaise interprétation courante. « Facilement découvrable » ne signifie pas « faible gravité ». Un bogue peut être simple à trouver et dangereux pour les nœuds affectés. À l'inverse, un problème obscur peut avoir un effet grave s'il est exploité, tout en justifiant plus de temps avant que les détails ne soient rendus publics. Les mainteneurs évaluent un rapport lors du triage et choisissent si la voie rapide s'applique. La politique publiée donne le critère et la réponse prévue, mais elle ne publie pas de seuil mécanique pour décider quels prompts, outils ou compétences comptent comme un effort minimal.

Antoine Poinsot, qui a proposé la modification du site web, a déclaré dans la discussion de la pull request que les mainteneurs avaient reçu davantage de rapports de failles faciles à redécouvrir. Il a attribué une grande partie du changement aux modèles de langage, qui réduisent l'effort nécessaire pour trouver certains problèmes ou identifier un correctif que les développeurs tentaient de garder discret. Selon lui, retenir les détails offre moins de protection lorsqu'une autre personne peut trouver la faiblesse de manière indépendante rapidement. Le même embargo peut retarder une version corrigée pour les opérateurs qui restent sur une ancienne branche prise en charge.

Pour un rapport placé dans la nouvelle catégorie, Bitcoin Core indique qu'il publiera une version corrective avec le correctif pour chaque version majeure maintenue et un avis en même temps. « Dès que possible » décrit une intention, pas un nombre fixe d'heures à partir du premier rapport. Les développeurs doivent encore confirmer le problème, écrire et réviser un correctif, le tester sur chaque branche et préparer les versions. La politique ne promet pas qu'une version non maintenue recevra un correctif ni que tous les opérateurs auront mis à jour avant la publication de l'avis.

L'ancien embargo pourrait survivre à plusieurs versions

Les divulgations ordinaires suivent un calendrier différent. La politique indique que les vulnérabilités de faible gravité sont divulguées deux semaines après la publication d'une version majeure contenant le correctif. Les problèmes de gravité moyenne et élevée sont divulgués deux semaines après que la dernière version affectée atteint sa fin de vie, environ un an après qu'une version majeure a inclus le correctif pour la première fois. Les mainteneurs font une préannonce deux semaines avant de révéler un problème sous embargo, indiquant combien de vulnérabilités ont été corrigées et leurs niveaux de gravité. Les failles critiques se situent en dehors de ce calendrier standard et nécessitent une réponse adaptée à l'incident.

Les notes de version 32.0 offrent une comparaison concrète. Elles indiquent que trois vulnérabilités de gravité moyenne ou élevée corrigées dans la version 30.0 seront divulguées deux semaines après la nouvelle version, tandis qu'aucune vulnérabilité de faible gravité corrigée dans la 32.0 n'était à divulguer selon ce calendrier. La version 30.0 est datée du 10 octobre 2025 dans le tableau de cycle de vie de Bitcoin Core. Le calendrier de publication de la version 32.0 enregistre son tag le 21 octobre 2026. Ces dates sont séparées de 376 jours, une comparaison arithmétique entre la date de correction plus ancienne et le tag plus récent, et non la date annoncée par le projet pour un avis individuel.

Les notes n'identifient pas les composants ni les conditions d'exploitation de ces trois failles. Selon le processus standard, un correctif peut rester disponible dans une version plus récente tandis que les détails restent privés jusqu'à ce que les anciennes branches affectées quittent la fenêtre de maintenance. La nouvelle voie ne change ce calcul que pour les bogues que les mainteneurs jugent facilement découvrables. Elle n'annule pas le long calendrier pour les cas de gravité moyenne et élevée plus difficiles à trouver.

Une divulgation passée montre l'ancienne voie en pratique. Bitcoin Core a divulgué CVE-2024-52911 en mai 2026 après que la faille avait déjà été corrigée dans la version 29.0, publiée en avril 2025. Un bloc spécialement conçu pouvait déclencher une condition d'utilisation après libération dans l'interpréteur de script et faire planter les nœuds vulnérables. Produire un bloc avec suffisamment de preuve de travail rendait l'attaque coûteuse, et le projet jugeait l'exécution de code à distance peu probable. L'écart entre le correctif et les détails publics faisait partie de l'approche de divulgation antérieure ; il ne prouve pas que l'ancien problème aurait répondu au critère de découverte facile actuel.

Trois versions maintenues définissent qui reçoit un correctif

Le cycle de vie logiciel de Bitcoin Core indique que les mainteneurs prennent en charge les trois dernières versions majeures. Lorsqu'une nouvelle version majeure arrive, la plus ancienne des trois atteint sa fin de vie et cesse généralement de recevoir des correctifs de sécurité. Avec la version 32.0 taguée le 21 octobre et ses notes de version indiquant que la version 29.x et les versions antérieures ont atteint leur fin de vie, les branches pour la nouvelle voie rapide sont 30.x, 31.x et 32.x. Une version corrective pour chacune de ces branches permettrait à un opérateur sur 30.x d'appliquer un correctif ciblé sans adopter immédiatement toutes les fonctionnalités et changements de comportement de la 32.0.

Le cycle de version candidate 32.0 a commencé le 14 septembre, et le projet a tagué la version stable le 21 octobre. La distinction entre un tag de version, un binaire et un nœud installé est importante. Le calendrier montre un tag 32.0 ; la distribution officielle et le déploiement propre à l'opérateur sont des étapes ultérieures. Sa page de cycle de vie affichait encore une date de publication « TBA » pour la 32.x au moment de la préparation de cet article, même si le calendrier de publication montrait le tag. Les notes de version 32.0 indiquent que la version 29.x et les versions antérieures ont atteint leur fin de vie. Bitcoin Core n'a pas encore mis à jour la date de la 32.x affichée sur son tableau de cycle de vie.

Une branche qui reste prise en charge n'est pas automatiquement corrigée. La politique indique que les correctifs seront rétroportés vers chaque version majeure maintenue, et la page de cycle de vie indique que le seuil de rétroportage augmente généralement à mesure qu'une branche vieillit. La nouvelle promesse de découverte facile est plus spécifique pour les bogues de sécurité qu'elle couvre. Maintenir trois lignes corrigées nécessite une révision et des tests à travers les différences de code, plutôt que de simplement copier un commit dans trois répertoires. Un correctif qui s'applique proprement à une branche peut nécessiter un travail différent sur une autre. Bitcoin Core n'a pas spécifié de limite de temps fixe pour ce travail.

Les opérateurs en dehors des trois branches font face à une décision différente. La version 29.x peut encore démarrer et valider des blocs ordinaires après sa fin de vie, mais elle ne recevra généralement pas de nouvelle version de correctif de sécurité. Un opérateur qui l'exécute doit passer à une branche maintenue pour obtenir les futurs correctifs. Bitcoin Core recommande la dernière version de maintenance de la version majeure la plus récente que l'opérateur peut adopter. Une entreprise disposant d'intégrations personnalisées ou de données de portefeuille peut avoir besoin de ses propres vérifications de compatibilité avant d'effectuer ce changement. La fin de vie décrit la limite de support du projet, et non un interrupteur qui éteint le vieux logiciel un jour donné.

La page de cycle de vie de Bitcoin Core établit une autre distinction qui peut se perdre dans une alerte de sécurité. Une version majeure est une branche, tandis qu'une version mineure est la mise à jour de maintenance sur cette branche. Quelqu'un exécutant 30.0 et quelqu'un exécutant 30.3 sont tous deux sur 30.x, mais ils n'ont pas nécessairement installé les mêmes correctifs. Si le projet publie une nouvelle version ponctuelle 30.x pour un bug facilement détectable, le simple fait de signaler qu'un service exécute « la version 30 » n'établirait pas la protection. Le numéro de version complet et la liste des correctifs de la version sont nécessaires. C'est pourquoi une entreprise déclarant avoir mis à niveau ses nœuds sans nommer la build déployée laisse la question centrale sans réponse.

Les notes de version de la version 32.0 décrivent comment une mise à niveau normale commence par l'arrêt de l'ancien logiciel et l'attente de sa fin avant d'installer le remplacement. Les opérateurs de nœuds disposant d'index de transactions, de portefeuilles ou d'applications connectées peuvent avoir des vérifications supplémentaires à effectuer. La documentation du projet indique que les versions de maintenance évitent normalement d'introduire des fonctionnalités majeures nouvelles, ce qui rend une version ponctuelle corrigée plus étroite qu'un saut vers une nouvelle branche majeure. Chaque déploiement doit toujours être testé par rapport au logiciel qui l'entoure.

Le correctif peut être public avant que la plupart des nœuds ne l'installent

Bitcoin Core n'a pas d'opérateur central qui peut pousser une mise à jour vers chaque nœud. Un particulier exécutant un nœud domestique peut télécharger une version peu après avoir vu un avis. Un dépositaire ou un échange peut tester une mise à niveau par rapport aux services internes, aux systèmes de portefeuille et à la surveillance avant de modifier les nœuds de production. Un pool de minage a un autre ensemble de dépendances de validation et de construction de blocs. Ce sont des possibilités opérationnelles, et non une liste mesurée de la rapidité avec laquelle chaque groupe a installé une mise à jour particulière de Bitcoin Core ; aucun décompte d'adoption n'accompagnait le changement de politique.

Un avis public modifie les informations disponibles pour les deux parties. Il peut décrire les versions affectées, l'impact et le correctif afin que les opérateurs puissent agir. Il peut aussi fournir des indices à quelqu'un qui teste d'anciens nœuds pour la même faiblesse. L'argument de Poinsot est que l'attaquant peut déjà trouver une faille facilement découvrable sans l'avis, tandis que les opérateurs ont moins de chances de corriger si les versions ponctuelles corrigées sont retenues jusqu'à une version majeure ultérieure. Cette position est une raison d'accélérer la réparation, et non une preuve que l'exposition disparaît une fois la version publiée.

Le mode de distribution compte autant que l'avis. Un opérateur de nœud doit obtenir le bon binaire ou paquet source, vérifier son authenticité selon le processus de publication du projet, arrêter le logiciel actuel en toute sécurité et redémarrer sur une version appropriée au déploiement. Un avertissement sur les réseaux sociaux ne remplace pas la version signée et l'avis officiel. Les notes de la version 32 de Bitcoin Core indiquent aux utilisateurs d'arrêter une version plus ancienne et d'attendre qu'elle se termine avant d'installer le nouveau logiciel. Les étapes sont banales, mais un changement de production précipité peut introduire sa propre panne si les dépendances de service ne sont pas prêtes.

La surveillance automatique peut aider une organisation à remarquer une version. Elle ne peut pas décider si son nœud en cours d'exécution est affecté par une vulnérabilité qui dépend d'une fonctionnalité ou d'une configuration particulière. Un avis devrait fournir suffisamment de détails pour hiérarchiser les systèmes concernés. Pendant l'intervalle entre la publication et le déploiement, les nœuds exposés au réseau restent une préoccupation pratique. Le projet n'a pas publié de temps médian mesuré pour que les opérateurs installent les versions de maintenance, de sorte que la question du titre ne peut pas recevoir de réponse avec un chiffre à l'échelle du réseau au 24 octobre.

Les rapports d'IA nécessitent une vérification avant toute alerte publique

La Bitcoin Red Team a fourni un exemple frappant de l'échelle que les revues assistées par IA peuvent produire. En août, crypto.news a rapporté 4 962 problèmes potentiels à travers 390 projets liés à Bitcoin au cours des premières 29,8 heures de revue du groupe. Le groupe a classé 720 comme élevés ou critiques et a déclaré que plus d'un cinquième des constats potentiels avaient été reproduits à la date du rapport. Ce sont les chiffres du groupe pour une gamme de projets, et non un décompte des vulnérabilités de Bitcoin Core ni un décompte vérifié de bugs exploitables.

La différence entre une découverte générée et une faille confirmée est au cœur de la nouvelle politique. Un modèle peut suggérer un chemin à travers le code, mais les mainteneurs doivent le reproduire, établir si un attaquant peut l'atteindre et déterminer quelles versions sont affectées. Une découverte dans un harnais de test peut ne pas être présente en production ; une vérification manquante dans une branche de code peut avoir un contrôle compensatoire ailleurs. La gravité exige d'examiner les préconditions et les conséquences réelles. La classification de divulgation rapide intervient après ce travail technique, et non lorsque un outil d'IA imprime une explication plausible.

Le dépôt du projet décrit la revue de code et les tests comme des goulots d'étranglement pour le développement. Un afflux de rapports de faible qualité pourrait consommer la même attention limitée nécessaire pour corriger un problème grave. À l'inverse, un rapport crédible et reproductible peut donner aux mainteneurs un avertissement plus précoce. Les instructions de signalement de sécurité de Bitcoin Core dirigent les découvertes sensibles vers son adresse e-mail de sécurité plutôt que vers un problème public. La mise à jour ne fait pas de la publication ouverte de détails d'exploitation non vérifiés une pratique recommandable pendant que les mainteneurs les vérifient encore.

Des groupes de sécurité Bitcoin ont demandé l'accès à l'IA de pointe en août pour soutenir le travail défensif. Le changement de politique distinct de Bitcoin Core traite des failles que d'autres utilisateurs des mêmes outils pourraient redécouvrir. Poinsot a déclaré que les mainteneurs avaient reçu davantage de tels rapports et avaient conclu que retenir un correctif offrait peu de protection dans ces cas.

Les quatre exemples de gravité de la politique de sécurité montrent pourquoi un seul avertissement ne peut convenir à chaque nœud. Un plantage déclenché à distance dans les paramètres par défaut peut perturber un service connecté publiquement. Une faille nécessitant une fonctionnalité spéciale activée sur un réseau local affecte un groupe plus restreint. Un problème dans la construction de modèles de blocs peut être urgent pour un mineur sans créer la même action immédiate pour un commerçant dont le nœud ne vérifie que les blocs entrants. Dans chaque cas, « facile à redécouvrir » mesure la facilité avec laquelle un attaquant peut prendre connaissance de la faiblesse, et non quels opérateurs ont la configuration affectée. L'avis doit porter les deux informations pour que le nouveau calendrier soit utile.

La liste historique des avis de Bitcoin Core comprend des conditions de déni de service qui ralentissent la propagation des blocs, épuisent la mémoire ou font planter un nœud, ainsi qu'un ancien bug d'inflation qui menaçait le consensus. Ce ne sont pas des classes d'incidents interchangeables. La politique exclut explicitement les bugs critiques du calendrier standard, préservant la possibilité d'une réponse adaptée au risque pour l'ensemble du réseau. La nouvelle voie de découverte facile doit donc être lue comme une décision de divulgation supplémentaire au sein du processus de sécurité du projet, et non comme l'affirmation que l'IA a modifié les règles de consensus de Bitcoin.

Les développeurs étaient en désaccord sur l'avertissement lui-même

La discussion sur la politique comprend une objection substantielle à la publication simultanée et à l'avertissement public. Le développeur Bitcoin Antoine Riard a soutenu sur la pull request qu'un avis pourrait provoquer une migration précipitée inutile parmi les utilisateurs qui ne sont pas affectés par le bug particulier. Son exemple distinguait un problème de modèle de bloc que les mineurs devraient traiter d'urgence d'un cas où les commerçants pourraient suivre un chemin de mise à niveau plus prudent. Une alerte de sécurité indifférenciée peut faire croire à chaque opérateur qu'il doit modifier immédiatement ses systèmes de production.

Riard n'a pas contesté que certains bugs sont faciles à découvrir. Il a remis en question le moment et le contenu d'une alerte envoyée à des opérateurs confrontés à différents niveaux de risque. Une publication rapide pourrait donner aux mineurs, commerçants, portefeuilles et plateformes d'échange une branche corrigée en même temps, tandis qu'un avis explique l'exposition différente pour chaque groupe. Si l'avis est trop vague, les opérateurs affectés peuvent ne pas reconnaître leur urgence ; s'il est trop large, ceux qui ne sont pas affectés peuvent prendre des mesures perturbatrices. La politique finale a conservé la promesse d'un avis accompagnant les versions ponctuelles et n'a pas spécifié de modèle unique pour décrire chaque rôle affecté.

L'argument opposé de Poinsot est qu'un secret plus long peut empêcher les anciennes branches prises en charge de recevoir un correctif, et qu'un bug facilement trouvé ne restera probablement pas caché simplement parce que le projet attend. Les deux positions acceptent que le déploiement soit lent et qu'un avis public puisse modifier les comportements. Ils diffèrent sur le risque qui domine pour une faille vérifiée particulière. La politique fait de « facile à découvrir » un jugement de triage, laissant aux mainteneurs le choix de la voie rapide uniquement lorsqu'ils estiment que le retard du correctif est plus difficile à justifier que le risque de divulgation.

Aucun des deux arguments n'établit que la publication est toujours inoffensive ou que le secret protège toujours les gens. Une faille très simple affectant un service réseau par défaut pourrait rendre la rapidité primordiale. Une faille affectant une configuration étroite et non par défaut pourrait mériter des instructions très spécifiques même si un modèle peut la décrire facilement. Les catégories de gravité et la nouvelle évaluation de découverte devraient ensemble façonner la note de version. Bitcoin Core n'a pas publié de liste de cas futurs, et aucun incident postérieur au changement n'établit encore dans quelle mesure l'approche fonctionne sur le terrain.

Core Lightning offre un exemple opérationnel différent

La politique de Bitcoin Core régit Bitcoin Core, pas chaque programme de l’écosystème Bitcoin. Les développeurs de Core Lightning ont fait face à leur propre volume de rapports générés par l’IA en août et ont confirmé que plusieurs soumissions décrivaient de véritables failles. En octobre, l’équipe a averti les opérateurs de nœuds plus anciens après des rapports d’attaques contre des systèmes exécutant la version 26.06.7 ou antérieure. Elle a exhorté à une mise à niveau vers une version plus récente. L’équipe n’avait pas identifié publiquement la méthode d’attaque ni confirmé de pertes d’utilisateurs dans cet avertissement, de sorte que les rapports ne doivent pas être traités comme la preuve d’un exploit particulier ni appliqués au code de Bitcoin Core.

L’exemple de Lightning montre pourquoi un correctif disponible ne suffit pas à achever la réponse de sécurité. Les opérateurs peuvent continuer à utiliser des logiciels plus anciens après l’existence de versions corrigées. Sa source du 26.06.7 d’août a d’abord été retenue pendant deux semaines afin que les opérateurs puissent installer la version avant que d’éventuels attaquants n’étudient les changements ; la publication ultérieure de la source et l’avertissement d’octobre ont suivi une séquence de divulgation différente de la nouvelle voie de découverte facile de Bitcoin Core. Le logiciel, la couche réseau et la menace étaient différents. Le fait pratique commun est qu’un avis ne protège un système que lorsque l’opérateur concerné le comprend et déploie la mise à jour correcte.

Certains opérateurs de nœuds Lightning ont été informés que l’exécution d’un démon hors ligne pouvait temporairement limiter l’exposition pendant qu’il continuait à surveiller la blockchain. Un opérateur de Bitcoin Core ne devrait pas importer cette instruction sans vérifier les exigences de sa propre application. Un nœud complet utilisé par un portefeuille, une plateforme d’échange ou un service Lightning peut avoir des obligations qui persistent même lorsque la connectivité réseau change. L’avis de Bitcoin Core pour une faille spécifique devra indiquer si un changement de configuration temporaire est utile. Aucun contournement général n’apparaît dans la politique du 22 octobre.

La différence entre « disponible » et « installé » est plus facile à voir lorsqu’une faille n’affecte pas toutes les configurations. Un mineur peut exécuter un service de modèles de blocs à côté de son nœud de validation. Une plateforme de garde peut isoler son processus Bitcoin Core de l’internet public mais autoriser des programmes internes à appeler son interface RPC. Un utilisateur domestique peut exécuter les paramètres réseau par défaut avec un portefeuille intégré. Une seule version corrective peut corriger les trois déploiements, mais l’exposition immédiate et le temps nécessaire pour tester une mise à jour peuvent différer. La politique publique de Bitcoin Core ne cherche pas à assigner une échéance universelle à ces opérateurs.

Un avis bien délimité pourrait indiquer les versions et paramètres affectés, les dommages qu’un exploit réussi pourrait causer, et si l’attaque nécessite un accès réseau, un accès local ou une action particulière de l’utilisateur. Le projet a utilisé ces distinctions dans des catégories d’avis antérieures. Les opérateurs peuvent alors comparer leurs propres configurations avec les conditions décrites. L’amendement du 22 octobre promet de publier un avis avec un correctif pour le groupe de découverte facile, mais les faits exacts divulgués dépendront du premier problème vérifié classé de cette manière.

La première divulgation rapide établira le rythme

Le changement écrit donne aux mainteneurs une nouvelle voie mais ne fournit encore aucune étude de cas. La séquence mesurable commence par un rapport vérifié et une classification, passe à des correctifs pour les trois branches maintenues, et se termine par des versions correctives signées et un avis. Les dates de ces étapes montreraient à quelle vitesse le projet peut rétroporter un correctif et si son avis public n’arrive que lorsque chaque branche est prête. Une version qui couvre deux des trois lignes maintenues ne correspondrait pas à la promesse publiée pour la nouvelle catégorie.

L’adoption par les opérateurs est plus difficile à observer. Les nœuds accessibles publiquement peuvent annoncer des versions logicielles, mais les explorations du réseau ne voient qu’un sous-ensemble des déploiements et les chaînes de version n’ont pas besoin de divulguer chaque service privé. Les plateformes d’échange et de garde peuvent utiliser des nœuds internes qui n’acceptent jamais de connexions publiques entrantes. Un chercheur qui rapporte un pourcentage de mise à niveau devrait expliquer l’échantillon et ses angles morts. Sans cela, le nombre pourrait sous-estimer la part d’infrastructure de production encore exposée ou la surestimer en comptant des nœuds publics dormants.

Les notes de la version 32.0 dirigent les opérateurs vers la liste d’annonces du projet pour les notifications de sécurité et de mise à jour. Sa page de cycle de vie recommande la dernière version de maintenance de la branche majeure la plus récente qu’un opérateur peut utiliser. La prochaine divulgation sous embargo est attendue deux semaines après la sortie de la 32.0 et décrira trois vulnérabilités de gravité moyenne ou élevée déjà corrigées dans la 30.0.

Ce qu'il faut surveiller

• Premier cas classifié : Un avis identifiant une faille facilement découvrable, ses versions affectées et la base de la publication rapide.
• Trois versions correctives : Les correctifs correspondants pour 30.x, 31.x et 32.x, ou une limite de maintenance mise à jour si une nouvelle version majeure arrive.
• Détail de l'avis : Des distinctions claires entre mineurs, commerçants, dépositaires et nœuds domestiques lorsque leur exposition réelle diffère.
• Adoption par les opérateurs : Des mesures de versions datées avec un échantillon explicite, ainsi que les divulgations des services qui exploitent des nœuds privés.
• Anciens cas en attente : Les trois correctifs de gravité moyenne ou élevée de la version 30.0 que les notes de la version 32.0 indiquent comme devant être expliqués après le délai habituel.

FAQ