Un processus de compilation automatisé a publié les images à partir d’une étiquette provisoire. Les responsables de la maintenance indiquent les avoir remplacées et avoir supprimé, pour chaque étiquette, toute référence aux manifestes incorrects. Mais un opérateur qui a conservé une image défectueuse ne peut pas se fier à la version affichée au démarrage pour confirmer que le correctif a été appliqué.
La publication du 28 août a imposé un embargo de 14 jours sur la publication du code source, ce qui indique une divulgation prévue le 11 septembre. Au 8 septembre, l’avis présente toujours cette publication comme à venir. Les responsables de la maintenance indiquent que ce délai donne aux opérateurs le temps de mettre à niveau leurs systèmes avant que d’éventuels attaquants puissent procéder à la rétro-ingénierie des correctifs.
Comment vérifier l’image Docker pour corriger le bug de Lightning
Les responsables de la maintenance demandent à toute personne ayant précédemment récupéré l’une des quatre étiquettes de comparer son condensat, le hachage qui identifie l’image, avec les valeurs corrigées :
Pour l’image standard avec numéro de version, l’avis fournit cette commande pour examiner l’image locale. À lui seul, son résultat ne permet pas d’établir quelle image exécute un conteneur existant :
docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7
Si le condensat diffère, la commande de téléchargement correspondante est :
docker pull elementsproject/lightningd:v26.06.7
L’avis fournit également docker pull elementsproject/lightningd:latest pour cette étiquette. Les utilisateurs de VLS doivent utiliser le condensat VLS distinct indiqué dans le tableau. Leur paramètre VLS_CLN_VERSION doit également correspondre à v26.06.7, sinon remote_hsmd_socket refusera de démarrer ; le signataire lui-même reste en version VLS v0.14.0.
Les utilisateurs ayant épinglé la version v26.06.6 ou une version antérieure ont échappé à cette erreur de conditionnement. Cette exemption concerne le conditionnement défectueux ; les nouveaux correctifs de sécurité sont intégrés à la version v26.06.7.
La correction du conditionnement change le problème immédiat de l’opérateur : toute tentative de mise à niveau pourrait devoir être vérifiée à nouveau tant que cette période reste ouverte.
Un autre piège lié au téléchargement existe pendant l’embargo. Les archives de code source automatiquement jointes par GitHub ne sont pas le code source de la version v26.06.7, avertissent les responsables de la maintenance ; compiler ces archives ne produira donc pas les binaires corrigés annoncés.