Bitcoin Core ha revisado su política de divulgación de vulnerabilidades, eliminando el período de embargo basado en la gravedad para los errores fáciles de descubrir, incluidos los problemas que pueden surgir de un simple prompt a un modelo de lenguaje. El desarrollador Antoine Poinsot registró el cambio en la política de seguridad del proyecto el 22 de octubre.

La actualización es una regla de divulgación, no un informe de un nuevo exploit, y no dice nada sobre la criptografía de Bitcoin ni sobre la seguridad de las claves privadas de los usuarios.

Por qué la IA debilitó el embargo

Los desarrolladores escribieron que recientemente habían visto más informes de vulnerabilidades que pueden encontrarse fácilmente, o encontrarse de nuevo. Lo atribuyeron en gran medida a los modelos de lenguaje, que reducen la barrera para detectar ciertas clases de errores y también pueden identificar correcciones encubiertas: parches de seguridad fusionados en el código sin ser etiquetados como tales.

Ese segundo punto debilita el propósito de un embargo, el período durante el cual los mantenedores retienen los detalles de una falla reportada mientras se prepara una versión corregida. Bitcoin Core es de código abierto, por lo que una corrección es visible en el código público mucho antes de que se publiquen sus detalles. Si un modelo puede reconocer un cambio como una corrección de seguridad, mantener el silencio hace poco para ocultar el error a los atacantes y, al mismo tiempo, retrasa una versión parcheada para los usuarios.

"El período de embargo logra poco, pero retrasa la disponibilidad de una versión corregida", escribieron los desarrolladores.

Los embargos prolongados también influyeron en dónde aterrizaban las correcciones. Los desarrolladores señalaron que su enfoque generalmente significaba que las correcciones de seguridad no podían retroportarse — llevarse a versiones anteriores que aún contaban con soporte — y llegaban a los usuarios solo con la siguiente versión principal.

Cómo cambia la nueva regla el cronograma

Los cronogramas existentes, establecidos en la página de avisos de seguridad del proyecto, muestran cuánto podría ser esa espera. Los desarrolladores deciden la clasificación cuando evalúan un informe.

Se espera que la nueva regla cubra los errores que pueden encontrarse con un esfuerzo mínimo, como mediante un simple prompt a un modelo de lenguaje, aunque no se limita a descubrimientos de IA. Para estos errores, el embargo basado en la gravedad ya no aplica, y los detalles pueden publicarse junto con la corregida en lugar de después de un período de espera.

Qué nodos reciben el parche

La política de mantenimiento de Bitcoin Core cubre las tres últimas versiones principales. Cuando se lanza una nueva, la más antigua llega al fin de vida y generalmente no recibe correcciones de seguridad.

Los nodos que aún ejecutan 28.x o versiones anteriores generalmente no recibirán estas correcciones. El proyecto apunta a una versión principal cada seis o siete meses, y la próxima, 32.0, sacará a 29.x de la ventana de mantenimiento. Bitcoin Core recomienda ejecutar la última versión de mantenimiento de la versión principal más reciente a la que un operador pueda actualizar, y su página de descargas explica cómo verificar las sumas de comprobación y firmas de las versiones.

El retroporte también depende de las personas. La página del ciclo de vida del proyecto señala que el umbral para retroportar un cambio aumenta a medida que una versión envejece, y que no siempre hay suficientes voluntarios para gestionarlo. La capacidad de mantenimiento también ha influido en otras decisiones, como lo demostró el debate anterior sobre el soporte de Bitcoin Core para la red de privacidad CJDNS.

La compensación, y qué observar

Los desarrolladores plantean cada política de seguridad como un equilibrio entre la transparencia, que ayuda tanto a atacantes como a defensores, y dar tiempo a los usuarios para actualizar, algo que la lenta cultura de actualización de Bitcoin Core hace más difícil. Publicar un aviso junto con las versiones corregidas significa que los detalles se hacen públicos mientras algunos nodos aún ejecutan software sin parches. Para los errores que los atacantes podrían encontrar por su cuenta, los desarrolladores consideran que una corrección rápida importa más que mantener los detalles en secreto.

El primer aviso de seguridad emitido bajo la nueva regla mostrará qué tan rápido llegan en la práctica las versiones puntuales — actualizaciones menores dentro de una versión principal — a las tres versiones mantenidas. Por separado, el lanzamiento de 32.0 reducirá el conjunto de nodos que pueden recibirlas.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento financiero ni de inversión. Los operadores de nodos deben seguir las notas de la versión oficiales de Bitcoin Core y las instrucciones de verificación.

Fuente: Coindoo