Bitcoin Core elimina el embargo de un año para fallos que una sola indicación de IA puede revelar

Por qué un embargo de un año dejó de tener sentido

La política anterior de Bitcoin Core vinculaba el momento de la divulgación con la gravedad. Los fallos de baja gravedad se hacían públicos dos semanas después del lanzamiento de la siguiente versión principal. Los fallos de gravedad media y alta se mantenían en privado hasta dos semanas después de que la última versión afectada llegara al final de su vida útil, un plazo que la propia política describe como «aproximadamente un año después del primer lanzamiento de una versión principal que incluya la solución».

Ese calendario tenía una razón de ser. Bitcoin Core es la implementación de referencia que utilizan la mayoría de los nodos de Bitcoin, y sus operadores actualizan el software lentamente. El largo embargo pretendía dar tiempo a la red para instalar el parche antes de que se hicieran públicos los detalles. La contrapartida era que, por lo general, las soluciones no se adaptaban a versiones anteriores, así que un operador con una versión más antigua tenía que esperar a la siguiente versión principal, que el proyecto aspira a lanzar aproximadamente cada seis meses.

La cautela es estructural, no accidental. Los cambios de consenso, como la actualización Taproot de Bitcoin, siguen un proceso lento y conservador precisamente para que los operadores puedan adoptarlos según su propio calendario.

«Dada la naturaleza de nuestro proyecto, junto con una cultura de actualización lenta, nuestra política de seguridad favorece un período de embargo más largo», escribió Poinsot. «Por lo general, esto significa que las soluciones de seguridad no pueden adaptarse a versiones anteriores y solo están disponibles para los usuarios con el siguiente lanzamiento de una versión principal».

La IA rompe esa lógica. Si un fallo puede volver a descubrirse con un análisis trivial de un LLM, ocultarlo no sirve de nada, porque la vulnerabilidad ya está al alcance de cualquiera que tenga un chatbot. «Para estos problemas que son fáciles de encontrar, esta es la contrapartida equivocada. El período de embargo consigue poco, pero retrasa la disponibilidad de una versión corregida», escribió Poinsot.

Qué cambia realmente con la nueva categoría «fácil de descubrir»

Con la política revisada, el plazo de divulgación ahora tiene una tercera opción. Durante la evaluación inicial, una vulnerabilidad puede clasificarse como «fácil de descubrir», es decir, como una que «puede descubrirse con un esfuerzo mínimo, por ejemplo, mediante una indicación sencilla para un LLM». La etiqueta no se limita a los fallos descubiertos con IA: depende del poco esfuerzo necesario para volver a descubrirlos, no de la herramienta utilizada para encontrarlos.

En esos casos, la respuesta cambia en todos los aspectos. En lugar de incluir una única solución en la siguiente versión principal, los responsables del mantenimiento adaptarán una solución para cada versión principal que siga contando con soporte, tres ramas según la regla de Bitcoin Core de dar soporte a sus tres versiones más recientes, y publicarán versiones de corrección lo antes posible. El aviso de seguridad se publica junto con el software corregido.

La escala de gravedad sigue rigiendo todos los demás casos. Los fallos de baja gravedad mantienen el plazo de dos semanas. Los de gravedad media y alta siguen sujetos al plazo de aproximadamente un año. Los fallos críticos, aquellos que podrían robar monedas a nivel de protocolo, inflar la oferta o dividir permanentemente la cadena, siguen fuera de la política estándar y se gestionan caso por caso, como siempre.

Esa excepción tiene una buena razón de ser. En la historia de Bitcoin Core, el fallo de inflación divulgado como CVE-2018-17144 en septiembre de 2018 era el tipo de vulnerabilidad que justificaba un tratamiento especial: podría haber permitido crear monedas al margen del calendario de emisión. La nueva vía de los fallos «fáciles de descubrir» no afecta a esa categoría: un fallo crítico seguirá recibiendo una respuesta específica, adaptada al riesgo para toda la red.

Dos semanas, un año o «lo antes posible»

La forma más sencilla de entender el cambio es como un desplome del plazo de divulgación. Un fallo de gravedad media corregido hoy normalmente se mantendría en privado durante unas 52 semanas, y solo se divulgaría dos semanas después de que la última versión afectada llegara al final de su vida útil. El mismo fallo, una vez clasificado como fácil de descubrir, se publica en una versión de corrección «lo antes posible», junto con el aviso correspondiente. Esa es la diferencia entre un año y el tiempo que, según la propia descripción de los responsables del mantenimiento, se tarde en redactar, revisar y probar un parche específico.

El compromiso de adaptar las soluciones a versiones anteriores es la otra mitad del cambio. Antes, por lo general, una solución no llegaba a los usuarios de una rama antigua que aún tuviera soporte, sino que llegaba con la siguiente versión principal. Ahora, un operador con una versión anterior que siga teniendo soporte puede instalar una versión de corrección específica sin adoptar todas las funciones y cambios de comportamiento de la versión principal más reciente. En una red donde las actualizaciones son lentas y deliberadas, esto cambia sustancialmente la rapidez con la que se puede implementar un parche.

El riesgo que señalaron los propios responsables del mantenimiento

La vía más rápida tiene un costo, y Poinsot lo dijo claramente en la solicitud de incorporación de cambios. «Esto es especialmente importante porque, bajo esta política, las mitigaciones no tendrán tanto “tiempo de prueba” en las ramas de desarrollo antes de llegar a los usuarios», escribió. Una solución que se publica en unos días pasa menos tiempo en revisión y pruebas que una que permaneció allí durante meses.

En el debate también hubo discrepancias sobre si la divulgación debería ser aún más rápida. Algunos colaboradores argumentaron que abrir una solicitud de incorporación de cambios para una solución puede alertar por sí mismo a los atacantes, porque es fácil vigilar el repositorio de forma automatizada, así que quizá habría que divulgarla a más tardar junto con el parche o antes, con instrucciones para mitigar el problema. Otro colaborador propuso publicar las soluciones con un aviso discrecional o aplazado. Poinsot rechazó esa propuesta y escribió que alertar a los usuarios sin dar detalles podría provocar una migración precipitada entre operadores que nunca estuvieron afectados.

El intercambio es importante porque muestra que la nueva política es un punto medio deliberado, no una opción evidente. El texto aprobado mantiene el aviso simultáneo a la solución y conserva todos los detalles, en lugar de una advertencia vaga.

Cuando aparece el primer error «fácil de descubrir»

Todavía no se ha clasificado ninguna vulnerabilidad en la nueva categoría, así que este es un cambio de proceso, no la divulgación de un error activo. La primera prueba real llegará cuando los encargados del mantenimiento señalen algo «fácil de descubrir» durante la clasificación y publiquen versiones de mantenimiento en las ramas que siguen recibiendo soporte, junto con un aviso simultáneo.

La señal más amplia es que la búsqueda de errores asistida por IA ya ha obligado al ecosistema de Bitcoin a actuar. Core Lightning recomendó a los operadores de nodos a principios de este año que actualizaran o se desconectaran, después de que se confirmara que eran correctos los informes de vulnerabilidades generados por IA. El cambio de política de Bitcoin Core es la implementación de referencia haciendo el mismo cálculo en la capa base del protocolo: cuando redescubrir algo cuesta poco, el secreto aporta poco, y lo único que retrasa un embargo prolongado es el lanzamiento de la solución.

Para los operadores de nodos, hoy no cambia nada. El ritmo de las actualizaciones sigue siendo el mismo. La diferencia se notará la próxima vez que un error se considere fácil de descubrir, cuando el parche y el aviso se publiquen juntos con menos antelación de la que la red ha tenido nunca.