Le 10 octobre 2025, le 14 octobre 2025, le 27 octobre 2026, le 10 novembre 2026. Quatre dates alignées : les deux premières correspondent à l’intégration des correctifs dans les versions, la troisième à la fin de vie de la dernière branche de publication contenant l’ancien code, et la quatrième seulement à la publication de l’avis. Du début à la fin, 396 jours. $CL
Si cela a été gardé sous le coude aussi longtemps, ce n’est pas qu’on ait oublié d’en parler. La règle est gravée dans le marbre : les détails des vulnérabilités moyennes à élevées ne sont publiés qu’une fois que toutes les branches concernées ont atteint leur fin de vie, puis deux semaines plus tard ; les vulnérabilités faibles sont divulguées deux semaines après la sortie de la version principale qui contient le correctif ; les plus graves sont traitées à part. Deux semaines de préavis sont également prévues avant la divulgation. Fin de vie le 27 octobre, publication le 10 novembre : exactement quatorze jours. $BNB
L’idée est de laisser aux opérateurs le temps de migrer vers une autre version. Le revers est tout aussi évident : le code corrigé traînait déjà dans les modifications publiques depuis septembre 2025, à la portée de quiconque voulait le chercher ; et les nœuds encore sur une ancienne version se retrouvent maintenant exposés par un avis qui explique clairement le fonctionnement. J’ai passé en revue la chronologie jointe à l’avis : signalement, ouverture de la modification, fusion, notification des fournisseurs — rien ne manque. Seule la « communication à tous » a été repoussée de plus d’un an. $BTC
L’avis ne mentionne aucune exploitation dans la nature.
Trois documents ont été publiés le même jour : une vulnérabilité élevée et deux moyennes, toutes portant un numéro de 2025, mais rendues publiques en 2026. Ceux qui comptabilisent les vulnérabilités par année risquent de mal classer cette série.
La règle a été modifiée une fois, le 22 octobre. Une nouvelle catégorie a été définie : les vulnérabilités « faciles à redécouvrir ». Si une simple consigne suffit à un grand modèle pour les trouver, elles ne sont plus gardées sous embargo : une version principale encore maintenue doit être corrigée au plus vite, et les informations publiées en même temps. Les trois vulnérabilités du 28 octobre, découvertes avec l’aide d’outils, ont suivi cette nouvelle procédure, sans attendre la fin de vie. En clair, une période de mise sous embargo de plus d’un an pourrait désormais devenir un cas rare.
À l’heure actuelle, les branches 30, 31 et 32 sont maintenues. Le jour de la fin de vie, la version 32.1 est sortie ; le lendemain, les versions 29.5, 30.4 et 31.2 étaient également disponibles. Pour les personnes qui utilisent ces versions, le 10 novembre n’a en réalité rien ajouté qu’elles soient obligées de faire.
Opinion personnelle, ne constitue pas un conseil en investissement. Vous êtes responsable de vos gains et de vos pertes.
#比特币Core披露Tor流量漏洞
Si cela a été gardé sous le coude aussi longtemps, ce n’est pas qu’on ait oublié d’en parler. La règle est gravée dans le marbre : les détails des vulnérabilités moyennes à élevées ne sont publiés qu’une fois que toutes les branches concernées ont atteint leur fin de vie, puis deux semaines plus tard ; les vulnérabilités faibles sont divulguées deux semaines après la sortie de la version principale qui contient le correctif ; les plus graves sont traitées à part. Deux semaines de préavis sont également prévues avant la divulgation. Fin de vie le 27 octobre, publication le 10 novembre : exactement quatorze jours. $BNB
L’idée est de laisser aux opérateurs le temps de migrer vers une autre version. Le revers est tout aussi évident : le code corrigé traînait déjà dans les modifications publiques depuis septembre 2025, à la portée de quiconque voulait le chercher ; et les nœuds encore sur une ancienne version se retrouvent maintenant exposés par un avis qui explique clairement le fonctionnement. J’ai passé en revue la chronologie jointe à l’avis : signalement, ouverture de la modification, fusion, notification des fournisseurs — rien ne manque. Seule la « communication à tous » a été repoussée de plus d’un an. $BTC
L’avis ne mentionne aucune exploitation dans la nature.
Trois documents ont été publiés le même jour : une vulnérabilité élevée et deux moyennes, toutes portant un numéro de 2025, mais rendues publiques en 2026. Ceux qui comptabilisent les vulnérabilités par année risquent de mal classer cette série.
La règle a été modifiée une fois, le 22 octobre. Une nouvelle catégorie a été définie : les vulnérabilités « faciles à redécouvrir ». Si une simple consigne suffit à un grand modèle pour les trouver, elles ne sont plus gardées sous embargo : une version principale encore maintenue doit être corrigée au plus vite, et les informations publiées en même temps. Les trois vulnérabilités du 28 octobre, découvertes avec l’aide d’outils, ont suivi cette nouvelle procédure, sans attendre la fin de vie. En clair, une période de mise sous embargo de plus d’un an pourrait désormais devenir un cas rare.
À l’heure actuelle, les branches 30, 31 et 32 sont maintenues. Le jour de la fin de vie, la version 32.1 est sortie ; le lendemain, les versions 29.5, 30.4 et 31.2 étaient également disponibles. Pour les personnes qui utilisent ces versions, le 10 novembre n’a en réalité rien ajouté qu’elles soient obligées de faire.
Opinion personnelle, ne constitue pas un conseil en investissement. Vous êtes responsable de vos gains et de vos pertes.
#比特币Core披露Tor流量漏洞
