Ein automatisierter Build-Prozess veröffentlichte die Images unter einem Platzhalter-Tag. Die Maintainer sagen, sie hätten sie ersetzt und alle Verweise der Tags auf die falschen Manifeste entfernt. Betreiber, die ein fehlerhaftes Image behalten haben, können sich jedoch nicht darauf verlassen, dass die beim Start angezeigte Version bestätigt, dass der Patch eingespielt wurde.

Eine Infografik zeigt fehlerhafte Core-Lightning-Docker-Images, die unter vier Tags bereitgestellt wurden, gefolgt von korrigierten Versionen und Hinweisen zur Überprüfung der Image-Digests.

Die Veröffentlichung vom 28. Aug. legte eine 14-tägige Sperrfrist für die Veröffentlichung des Quellcodes fest und verwies auf eine geplante Offenlegung am 11. Sept. Mit Stand vom 8. Sept. bezeichnet der Hinweis diese Veröffentlichung weiterhin als bevorstehend. Die Maintainer sagen, die Verzögerung gebe Betreibern Zeit für ein Upgrade, bevor potenzielle Angreifer die Fixes zurückentwickeln können.

So prüfst du das Docker-Image, um den Lightning-Fehler zu beheben

Die Maintainer bitten alle, die zuvor eines der vier Tags abgerufen haben, dessen Digest, den identifizierenden Hash des Images, mit den korrigierten Werten zu vergleichen:

Für das standardmäßige Image mit Versionsnummer enthält der Hinweis diesen Befehl, um das lokale Image zu prüfen. Seine Ausgabe allein belegt nicht, welches Image ein vorhandener Container ausführt:

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

Wenn der Digest abweicht, lautet der zugehörige Download-Befehl:

docker pull elementsproject/lightningd:v26.06.7

Für dieses Tag enthält der Hinweis außerdem docker pull elementsproject/lightningd:latest. VLS-Nutzer benötigen den separaten VLS-Digest aus der Tabelle. Auch ihre Einstellung VLS_CLN_VERSION muss mit v26.06.7 übereinstimmen, sonst startet remote_hsmd_socket nicht; der Signer selbst bleibt bei VLS v0.14.0.

Nutzern mit fest eingestellter Version v26.06.6 oder älter blieb dieser Verpackungsfehler erspart. Diese Ausnahme betrifft die fehlerhafte Verpackung; die neuen Sicherheitsfixes sind in v26.06.7 enthalten.

Die Korrektur der Verpackung ändert das unmittelbare Problem der Betreiber: Ein bereits versuchtes Upgrade muss möglicherweise erneut überprüft werden, solange dieses Zeitfenster noch offen ist.

Während der Sperrfrist gibt es eine weitere Download-Falle. Die automatisch angehängten Quellcodearchive von GitHub sind nicht der Quellcode von v26.06.7, warnen die Maintainer. Ein Build dieser Archive erzeugt daher nicht die angekündigten gepatchten Binärdateien.