Signal does not write key to safeStorage on GNOME

[minosimo]

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]

If you installed for your user:

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

(Otherwise, remove the --user)

[minosimo]

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]

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]

I will try to confirm that, it seems like signalapp/Signal-Desktop#7029 is likely referencing the Flathub issue.

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

[minosimo]

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.

signalapp/Signal-Desktop#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.

signalapp/Signal-Desktop#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]

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

[Fabi555]

Uninstall Signal from Flathub and install with instruction from signal.org . Work without problems.
https://signal.org/download/

[minosimo]

When installed from the .deb, Signal 7.26.0 and 7.24.1 write to the keyring without issue on Ubuntu 24.04 and Debian 12.

The flathub build 7.24.1 fails to write on all GNOME systems I've tried.

The flathub build 7.24.1 should be on Electron 32.1.0. Electron Fiddle writes to the keyring with no issues on that version.

[minosimo]

I've narrowed it down a bit more. The crash that was reported in the PR still happens reliably with the build currently on Flathub. To reproduce, start Signal with the backend set to gnome-libsecret, from a fresh install or with an unencrypted key in config.json. I tested this on Ubuntu 24.04 and Fedora 40.

1. Signal encrypts the database key and tries to write the key to the keyring.
2. The keyring daemon crashes.
3. The entry that gets written has no label, and an incorrect attribute app_id org.signal.Signal. This follows the format of keys written by other flatpaks that do not use Electron. The value is a unicode string that is different each time, even through the same key is being encrypted.
4. On next launch the database is inaccessible.

If I write a Signal key to the keyring using Electron Fiddle, or check a keyring entry created by the .deb package of Signal, it is labeled "Chromium Safe Storage" and has the attribute application Signal.

[bermeitinger-b]

But by default, it doesn't use the keyring. So a fresh start should work as before.

[minosimo]

Of course, "fresh install" with the keyring set to gnome-libsecret. The intended behavior of Signal is to write to the keyring, the current fix that reverts to plaintext is a deviation from upstream.

I still have not seen any evidence that this is an upstream bug. If it is, could you please open this again until someone has found and linked the upstream issue.

[gichiba]

I didn't make a backup, and begrudgingly blew away my database and built up some conversation history with a fresh install, only to have it borked again 4 days later. every time Signal flathub starts up, it seems to be on a corrupted database (from what I can tell inaccessible due to a missing key... I don't really know I just came here to validate that yes, this is still an unresolved issue).

Sincerely, frustrated user on Pop!_OS

[minosimo]

So it turns out there is an application to read flatpak secrets after all, called Key Rack. The secrets on the main page are the flatpak ones, theoretically the key in there is the decryption key for the "encryptedKey" string in config.json.

If you take the key from Key Rack, put it in a normal entry with label Chromium Safe Storage and attribute application Signal, then launch Signal from the no-gcrypt PR with keystore set to gnome-libsecret, it should work. I still get a database decryption error but will experiment more tomorrow.

[frigginglorious]

Any luck with this @minosimo ?

My research has lead me to try and experiment with configs in something called flatseal, and I'll try that now. But cryptography has never been my strong suit, and I'm mostly at a loss for how to fix this.

Do I have the issue right? Though all signal data in transit is done with its sweet triple ratchet encryption, its always been stored on local devices in plain text. Now, they added an update that encrypts messages on local devices, and this is what has broken for some folks - myself included.

I'm on Fedora Linux 40 (Workstation Edition) on a Framework 16 laptop.