flathub / org.signal.Signal

https://flathub.org/apps/details/org.signal.Signal
61 stars 37 forks source link

Signal does not write key to safeStorage on GNOME #754

Closed minosimo closed 2 hours ago

minosimo commented 2 hours ago

Start with an old Signal install with the plaintext encryption key in conf.json. Run signal using gnome-libsecret for the backend.

1) config.json is updated with the encrypted key, and the "safeStorageBackend": "gnome_libsecret" entry 2) Signal launches, but does not write the key to the secrets backend 3) Upon next launch, Signal cannot decrypt the database and presents a database error

The key is supposed to be written to an entry called Chromium Safe Storage, with the Application field set to "Signal". This appears to mainly affect GNOME, though other DEs and configurations might be affected.

bermeitinger-b commented 2 hours ago

If you installed for your user:

flatpak override --user --env=SIGNAL_PASSWORD_STORE=gnome-libsecret org.signal.Signal

(Otherwise, remove the --user)

minosimo commented 2 hours ago

Please re-open this an reread the issue, this bug is the core of that broken update that was pushed a few days ago, and was never resolved.

As I said, I am launching Signal with gnome-libsecret. I check the console log to confirm it is using gnome-libsecret. The key is encrypted, which wouldn't happen if it weren't using gnome-libsecret.

The key never appears in the keyring. I confirm this with Seahorse.

I tried encrypting the key using Electron Fiddle AppImage, and it works fine. Once the key is written to the keyring and config.json is updated, I can continue using Signal with the backend set to gnome-libsecret.

Clearly, something prevents Signal specifically from successfully writing to the keyring on GNOME. Maybe it's an Electron version, or something else, I don't know, that's why I opened the issue.

bermeitinger-b commented 2 hours ago

If you set it to gnome-libsecret and it's using gnome-libsecret but fails, it's a Signal issue, not flatpak.

The initial issue did not come from this flatpak version.

minosimo commented 2 hours ago

I will try to confirm that, it seems like https://github.com/signalapp/Signal-Desktop/issues/7029 is likely referencing the Flathub issue.

Ok yes there are other reports from snap and .deb installs.

minosimo commented 42 minutes ago

After a decent amount of time reading issue trackers, I have not found any reports of a bug in Signal, gnome-keyring, nor Electron that would be responsible for this particular issue.

https://github.com/signalapp/Signal-Desktop/issues/6970 appears to be people who have disabled their DE's storage backend, are using the Flatpak, are using Firejail (which is apparently a known, separate issue), or something else that interferes with the database being opened.

ronidee has a different issue: his key is successfully decrypted, but incorrect, which presumably means the key was written but maybe malformed or something.

jenkniss reports his team were using the snap, but the error in the log is different from what you'd expect if the key could not be read from the keyring.

waynongithub could not access the key, but it had to do with the path getting changed when upgrading from Mint 20.3 > 21.3. Fixing the path restored access to Signal: means the key was in the keyring.

https://github.com/signalapp/Signal-Desktop/issues/7029 Never followed up with more info. The discussion turns quickly to Flathub.

Some brief testing:

System Source Result
Ubuntu 24.04 .deb from signal.org Key writes to keyring
Ubuntu 24.04 Snap Does not appear to use keyring?
Ubuntu 24.04 Flatpak from Flathub X
Fedora 40 Flatpak from Flathub X
Fedora 41 Flatpak from Flathub X
minosimo commented 39 minutes ago

If this issue is in fact tracked somewhere else, could you please like it when you have a minute? I remember mentions of an Electron bug, but I haven't managed to find it again.