В результате автоматической сборки образы были опубликованы с тегом-заполнителем. Сопровождающие проект утверждают, что заменили их и удалили все ссылки тегов на неверные манифесты. Но оператор, сохранивший неисправный образ, не может полагаться на отображаемую при запуске версию, чтобы убедиться, что патч установлен.

Инфографика показывает неисправные образы Core Lightning в Docker, опубликованные под четырьмя тегами, а затем исправленные релизы и рекомендации по проверке дайджестов образов.

В релизе от 28 августа был установлен 14-дневный период эмбарго на публикацию исходного кода, что указывало на запланированное раскрытие информации 11 сентября. По состоянию на 8 сентября в уведомлении эта публикация всё ещё обозначена как предстоящая. Сопровождающие проект утверждают, что задержка даёт операторам время обновиться до того, как потенциальные злоумышленники смогут провести обратный анализ исправлений.

Как проверить образ Docker и устранить ошибку Lightning

Сопровождающие проект просят всех, кто ранее загрузил один из четырёх тегов, сравнить его дайджест, то есть идентифицирующий хеш образа, с исправленными значениями:

Для стандартного образа с номером версии в уведомлении приводится эта команда для проверки локального образа. По одному лишь её выводу нельзя определить, какой образ запущен в существующем контейнере:

docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7

Если дайджест отличается, соответствующая команда загрузки выглядит так:

docker pull elementsproject/lightningd:v26.06.7

В уведомлении также приводится команда docker pull elementsproject/lightningd:latest для этого тега. Пользователям VLS нужен отдельный дайджест VLS из таблицы. Значение параметра VLS_CLN_VERSION также должно быть v26.06.7, иначе remote_hsmd_socket откажется запускаться; сама программа-подписант остаётся на версии VLS v0.14.0.

Пользователи, закрепившие версию v26.06.6 или более раннюю, избежали этой ошибки упаковки. Это исключение касается ошибочной упаковки; новые исправления безопасности относятся к v26.06.7.

Исправление упаковки меняет непосредственную проблему оператора: попытку обновления, возможно, придётся проверить ещё раз, пока это окно возможностей остаётся открытым.

Во время эмбарго есть и другая ловушка при загрузке. Сопровождающие проект предупреждают, что автоматически прикреплённые GitHub архивы исходного кода не являются исходным кодом v26.06.7, поэтому сборка из этих архивов не создаст заявленные бинарные файлы с патчем.