10 de octubre de 2025, 14 de octubre de 2025, 27 de octubre de 2026, 10 de noviembre de 2026. Cuatro fechas en fila: las dos primeras son cuando los parches llegaron a las versiones; la tercera, cuando dejó de recibir soporte la última rama de lanzamiento con el código antiguo; la cuarta, cuando por fin se hizo público el aviso. De principio a fin, 396 días. $CL
No es que se olvidaran de comunicarlo durante tanto tiempo. La regla está fijada: los detalles de gravedad media o alta no se hacen públicos hasta que todas las ramas de lanzamiento afectadas hayan llegado al fin de su vida útil, y se espera dos semanas más; los de gravedad baja se publican dos semanas después, junto con la versión principal que incluye la corrección; la categoría más grave se trata por separado. Además, antes de la divulgación hay dos semanas de aviso previo. El soporte terminó el 27 de octubre y el aviso se hizo público el 10 de noviembre: justo catorce días. $BNB
El motivo es darles a los operadores un margen para actualizar de versión. El costo también está a la vista: el código corregido ya figuraba en los cambios públicos desde septiembre de 2025, así que cualquiera podía encontrarlo; ahora, los nodos que siguen en versiones antiguas quedan expuestos por un aviso que explica claramente el principio de la vulnerabilidad. Revisé la cronología adjunta al aviso: informe, apertura del cambio, integración, notificación a los proveedores; no falta ningún paso. Lo único que se pospuso hasta más de un año después fue «contárselo a todo el mundo». $BTC
El aviso no menciona ningún caso de explotación activa.
Tres documentos se publicaron el mismo día: uno de gravedad alta y dos de gravedad media. Todos tienen números de identificación de 2025, aunque se hicieron públicos en 2026. Quienes cuentan las vulnerabilidades por año se equivocarán al clasificar esta tanda.
El 22 de octubre se cambió la regla. Se creó una nueva categoría: «fáciles de volver a descubrir». Si basta con una indicación sencilla para que un modelo de lenguaje grande las encuentre, ya no se mantienen en reserva: se publica cuanto antes una revisión para la versión principal que recibe mantenimiento, y la información se divulga al mismo tiempo. Los tres casos del 28 de octubre, encontrados con ayuda de herramientas, siguieron esta nueva vía; no esperaron al fin del soporte. En pocas palabras, es posible que mantenerlos en reserva durante más de un año pase a ser algo excepcional.
Actualmente reciben mantenimiento las ramas 30, 31 y 32. El día en que terminó el soporte se publicó la versión 32.1; al día siguiente también quedaron listas las versiones 29.5, 30.4 y 31.2. Quienes usan estas versiones, en realidad, no tuvieron que hacer nada nuevo ese 10 de noviembre.
Opinión personal; no constituye asesoramiento de inversión. Cada cual asume sus propias ganancias y pérdidas.
#比特币Core披露Tor流量漏洞
No es que se olvidaran de comunicarlo durante tanto tiempo. La regla está fijada: los detalles de gravedad media o alta no se hacen públicos hasta que todas las ramas de lanzamiento afectadas hayan llegado al fin de su vida útil, y se espera dos semanas más; los de gravedad baja se publican dos semanas después, junto con la versión principal que incluye la corrección; la categoría más grave se trata por separado. Además, antes de la divulgación hay dos semanas de aviso previo. El soporte terminó el 27 de octubre y el aviso se hizo público el 10 de noviembre: justo catorce días. $BNB
El motivo es darles a los operadores un margen para actualizar de versión. El costo también está a la vista: el código corregido ya figuraba en los cambios públicos desde septiembre de 2025, así que cualquiera podía encontrarlo; ahora, los nodos que siguen en versiones antiguas quedan expuestos por un aviso que explica claramente el principio de la vulnerabilidad. Revisé la cronología adjunta al aviso: informe, apertura del cambio, integración, notificación a los proveedores; no falta ningún paso. Lo único que se pospuso hasta más de un año después fue «contárselo a todo el mundo». $BTC
El aviso no menciona ningún caso de explotación activa.
Tres documentos se publicaron el mismo día: uno de gravedad alta y dos de gravedad media. Todos tienen números de identificación de 2025, aunque se hicieron públicos en 2026. Quienes cuentan las vulnerabilidades por año se equivocarán al clasificar esta tanda.
El 22 de octubre se cambió la regla. Se creó una nueva categoría: «fáciles de volver a descubrir». Si basta con una indicación sencilla para que un modelo de lenguaje grande las encuentre, ya no se mantienen en reserva: se publica cuanto antes una revisión para la versión principal que recibe mantenimiento, y la información se divulga al mismo tiempo. Los tres casos del 28 de octubre, encontrados con ayuda de herramientas, siguieron esta nueva vía; no esperaron al fin del soporte. En pocas palabras, es posible que mantenerlos en reserva durante más de un año pase a ser algo excepcional.
Actualmente reciben mantenimiento las ramas 30, 31 y 32. El día en que terminó el soporte se publicó la versión 32.1; al día siguiente también quedaron listas las versiones 29.5, 30.4 y 31.2. Quienes usan estas versiones, en realidad, no tuvieron que hacer nada nuevo ese 10 de noviembre.
Opinión personal; no constituye asesoramiento de inversión. Cada cual asume sus propias ganancias y pérdidas.
#比特币Core披露Tor流量漏洞
