Qué pasó
El 3 de julio de 2024, Antoine Poinsot publicó una política de divulgación de seguridad en la lista de correo de desarrollo de Bitcoin, en nombre de seis colaboradores. Horas después el proyecto publicó diez avisos de una vez, sobre vulnerabilidades corregidas en versiones hasta la 0.21.0 inclusive.
La política ordena los reportes en cuatro clases. Low son "bugs which are hard to exploit or have a low impact", Medium son "bugs with limited impact", High son "bugs with significant impact", y Critical son "bugs which threaten the whole network's integrity. For instance an inflation or coin theft bug."
Los plazos se desprenden de la clase. Los fallos de severidad baja se divulgan dos semanas después de publicarse una versión corregida. Los de severidad media y alta esperan hasta dos semanas después de que la última versión afectada llegue al fin de su vida útil, cerca de un año después de la corrección. Los críticos quedan fuera del calendario por completo, porque "would most likely require an ad-hoc procedure."
El atraso se está saldando por orden: los fallos corregidos en 22.0 más adelante en julio, los de 23.0 en agosto, "and so on until we run out of EOL versions".
Qué cambia
Cambia lo que sabe quien opera un nodo al decidir si actualiza, y ese es todo el punto.
Bitcoin no tiene mecanismo de actualización, y es deliberado. Nadie puede empujar un parche a ninguna máquina, y un nodo que corre una versión de hace cuatro años seguirá validando bloques indefinidamente. Quedarse en una versión vieja es, por lo tanto, una decisión de riesgo que alguien está tomando, y hasta ahora la tomaba sin información.
El anuncio es inusualmente franco sobre por qué había que corregir esto. El proyecto "has historically done a poor job at publicly disclosing security-critical bugs, whether externally reported or found by contributors", y el resultado es que mucha gente llegó a creer que Bitcoin Core sencillamente no tiene fallos. Esa impresión, dice, es "dangerous and, unfortunately, not accurate."
El archivo que se abrió ese mismo día vuelve concreta la distancia. Uno de los diez, un fallo que permitía a una transacción sin confirmar bien construida bloquear un nodo durante horas, se reportó en marzo de 2019 y se corrigió en 0.18.0 dos meses después. Se divulgó cinco años después de que llegara la corrección.
Qué no cambia
No vuelve seguras a las versiones viejas y no obliga a nadie a actualizar. Publica la información y deja la decisión donde ya estaba.
Tampoco dice nada sobre fallos aún no encontrados. El calendario rige vulnerabilidades ya conocidas y corregidas, así que una versión actual sin avisos publicados no es una versión sin defectos.
El caso más difícil queda excluido de forma explícita. Un fallo crítico, de la categoría de inflación o robo, no tiene plazo alguno, porque coordinar una corrección sin avisarle antes a un atacante es un problema que ninguna política resuelve por adelantado.
Contexto
La práctica anterior era corregir en silencio y publicar. No siempre fue posible: el fallo de inflación en 0.16.3, en septiembre de 2018, fue lo bastante grave como para tener que explicarse en su momento. Pero los más discretos salían sin anuncio, y algunos se retuvieron durante años por decisión deliberada más que por descuido.
Esto es práctica corriente en otros ámbitos. La mayoría del software mantenido publica avisos con un calendario, bajo alguna forma de divulgación coordinada. Lo que lo vuelve incómodo acá es que este software valida dinero para gente con la que no se puede contactar, en máquinas que quizá nunca se actualicen, y la divulgación les llega a ellas y a un atacante en el mismo momento. La respuesta de la política es esperar a que las versiones afectadas queden fuera de soporte, y entonces decirlo todo.