Repository navigation
Conversation
The bridge saved an encrypted copy of the login key map to data/lcs_secure_<id>.json, relative to its working directory. Docker and the README's native steps both start the bridge inside data/, so the write targeted data/data/ and failed on every login with "failed to save E2EE secure data". The key map is already stored in the user login metadata, which is loaded last and wins, so the file was never needed. Stop writing the file and keep reading old files as a fallback. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YLetjAVceT9hFiBGm9qiTG
highesttt
requested changes
Oct 26, 2026
highesttt
left a comment
Collaborator
There was a problem hiding this comment.
Two nitpicks: every connect still decrypts the old key file, and the old files are left on disk.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every login logs
failed to save E2EE secure data, because the bridge writes a key file that it does not need todata/data/, a folder that does not exist. Please review this change, which stops writing that file, and say if the file reading must go too.Chaque connexion affiche
failed to save E2EE secure data, car le bridge écrit un fichier de clés dont il n'a pas besoin dansdata/data/, un dossier qui n'existe pas. Merci de relire ce changement, qui arrête d'écrire ce fichier, et de dire si la lecture du fichier doit aussi disparaître.🇬🇧 More details · 3 min read
Summary
The bridge no longer writes
lcs_secure_<id>.json. It still reads an old file if one exists. The E2EE key map stays in the user login metadata, as before.Why
pkg/e2ee/manager.gobuilds the path asfilepath.Join("data", ...). This path is relative to the working directory. The Docker image starts the bridge in/data(Dockerfile:WORKDIR /data,docker-run.sh:cd /data). The README's native steps also runcd datafirst. So the write goes one folder too deep:beeper-line/data/lcs_secure_<id>.jsondata/(Docker, README native steps)data/data/lcs_secure_<id>.jsonno such file or directoryLog from a fresh Docker setup on
72c7a51, at QR login:Messages still decrypt, because the key map is also in the login metadata.
connectloads the metadata last, so it wins over the file (pkg/connector/client.go):So the file is a second copy of the key that nothing needs.
Changes
pkg/connector/connector.go: remove the file write after a new login, and removeloginSecureDataID, which only the writes used.pkg/connector/client.go: remove the file writes after a re-login and inrefreshLoginE2EEKeys.pkg/e2ee/manager.go: removeSaveSecureDataToFileandEncryptSecureBlob. KeepLoadSecureDataFromFileas a fallback for files from older versions.pkg/connector/login_keys_test.go: remove the test forloginSecureDataID.Another option is to remove
LoadSecureDataFromFileand its call too. That is cleaner, but a login from before the metadata copy existed (July 2026) can depend on its file. I kept the fallback for that case. I can remove it if you prefer.How it was tested
In a
golang:1.26-alpine3.23container witholm-dev, because the host has no libolm:gofmt -l pkg cmd: no output.go build ./...: passed.go vet $(go list ./... | grep -v /ltsm): passed.go test ./pkg/connector/... ./pkg/e2ee/...: passed.goimports -local github.com/beeper/line -l pkg cmd: no output.staticcheck $(go list ./... | grep -v /ltsm): one finding, inpkg/line/password/password.go:27. This PR does not change that file.Live, on the same Docker setup and
data/folder:72c7a51: a QR login logged thefailed to save E2EE secure datawarning.2990e09): a QR login over the existing login logged no warning or error.bbctl whoamishows the bridgeCONNECTED, and nolcs_secure_*.jsonfile exists in/data.Not tested (and why)
🇫🇷 Plus de détails · 3 min de lecture
Résumé
Le bridge n'écrit plus
lcs_secure_<id>.json. Il lit encore un ancien fichier s'il en existe un. La table des clés E2EE reste dans les métadonnées de connexion, comme avant.Pourquoi
pkg/e2ee/manager.goconstruit le chemin avecfilepath.Join("data", ...). Ce chemin est relatif au dossier de travail. L'image Docker lance le bridge dans/data(Dockerfile:WORKDIR /data,docker-run.sh:cd /data). Les étapes natives du README font aussicd datad'abord. L'écriture va donc un dossier trop loin :beeper-line/data/lcs_secure_<id>.jsondata/(Docker, étapes natives du README)data/data/lcs_secure_<id>.jsonno such file or directoryLog d'une installation Docker neuve sur
72c7a51, à la connexion par QR code :Les messages se déchiffrent quand même, car la table des clés est aussi dans les métadonnées de connexion.
connectcharge les métadonnées en dernier, donc elles l'emportent sur le fichier (pkg/connector/client.go) :Le fichier est donc une deuxième copie de la clé dont rien n'a besoin.
Modifications
pkg/connector/connector.go: supprime l'écriture du fichier après une nouvelle connexion, et supprimeloginSecureDataID, utilisé seulement par les écritures.pkg/connector/client.go: supprime les écritures du fichier après une reconnexion et dansrefreshLoginE2EEKeys.pkg/e2ee/manager.go: supprimeSaveSecureDataToFileetEncryptSecureBlob. GardeLoadSecureDataFromFilecomme solution de repli pour les fichiers des anciennes versions.pkg/connector/login_keys_test.go: supprime le test deloginSecureDataID.Une autre option est de supprimer aussi
LoadSecureDataFromFileet son appel. C'est plus propre, mais une connexion d'avant la copie dans les métadonnées (juillet 2026) peut dépendre de son fichier. J'ai gardé la solution de repli pour ce cas. Je peux la supprimer si vous préférez.Tests effectués
Dans un conteneur
golang:1.26-alpine3.23avecolm-dev, car l'hôte n'a pas libolm :gofmt -l pkg cmd: aucune sortie.go build ./...: réussi.go vet $(go list ./... | grep -v /ltsm): réussi.go test ./pkg/connector/... ./pkg/e2ee/...: réussi.goimports -local github.com/beeper/line -l pkg cmd: aucune sortie.staticcheck $(go list ./... | grep -v /ltsm): un résultat, danspkg/line/password/password.go:27. Cette PR ne modifie pas ce fichier.En direct, avec la même installation Docker et le même dossier
data/:72c7a51: une connexion par QR code a affiché l'avertissementfailed to save E2EE secure data.2990e09) : une connexion par QR code sur la connexion existante n'a affiché aucun avertissement ni aucune erreur.bbctl whoamimontre le bridgeCONNECTED, et aucun fichierlcs_secure_*.jsonn'existe dans/data.Non testé (et pourquoi)
🤖 Generated with Claude Code using clins:create-pr