Un proceso de compilación automatizado publicó las imágenes con una etiqueta provisional. Los mantenedores dicen que las reemplazaron y eliminaron de todas las etiquetas las referencias a los manifiestos incorrectos. Pero un operador que conservó una imagen defectuosa no puede confiar en la versión que aparece al iniciarla para confirmar que se aplicó el parche.
La versión del 28 de agosto estableció un embargo de 14 días para publicar el código fuente, lo que apuntaba a una divulgación prevista para el 11 de septiembre. Al 8 de septiembre, el aviso todavía describe esa publicación como algo que tendrá lugar próximamente. Los mantenedores dicen que el retraso da tiempo a los operadores para actualizar antes de que posibles atacantes puedan aplicar ingeniería inversa a las correcciones.
Cómo comprobar la imagen de Docker para corregir el error de Lightning
Los mantenedores piden a quienes hayan descargado anteriormente una de las cuatro etiquetas que comparen su resumen criptográfico, el hash que identifica la imagen, con los valores corregidos:
Para la imagen estándar con versión, el aviso proporciona este comando para inspeccionar la imagen local. Por sí sola, su salida no permite determinar qué imagen está ejecutando un contenedor existente:
docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7
Si el resumen criptográfico no coincide, el comando correspondiente para descargar la imagen es:
docker pull elementsproject/lightningd:v26.06.7
El aviso también proporciona docker pull elementsproject/lightningd:latest para esa etiqueta. Los usuarios de VLS necesitan el resumen criptográfico independiente de VLS que aparece en la tabla. Su ajuste VLS_CLN_VERSION también debe coincidir con v26.06.7, o remote_hsmd_socket no se iniciará; el firmante en sí sigue siendo VLS v0.14.0.
Los usuarios que tenían fijada la versión v26.06.6 o una anterior no se vieron afectados por este error de empaquetado. La exención se refiere al empaquetado defectuoso; las nuevas correcciones de seguridad corresponden a v26.06.7.
La corrección del empaquetado cambia el problema inmediato del operador: puede que tenga que volver a comprobar una actualización que ya intentó mientras esa ventana siga abierta.
Durante el embargo existe otra trampa al descargar los archivos. Los mantenedores advierten que los archivos del código fuente que GitHub adjunta automáticamente no son el código fuente de v26.06.7, por lo que compilarlos no producirá los binarios corregidos anunciados.