I’ve run into an issue with Signal Messenger on Whonix that I’d like some input on.
Signal uses Electron Safestorage to securely store its private keys in the local system’s keyring. However, it seems that Electron Safestorage isn’t included by default in Whonix, nor is it listed as a dependency when installing Signal Messenger on the Whonix Workstation.
Because of this, no keyring is generated to store Signal’s private keys securely. Instead, the keys end up being saved in plain text on the local system, which is obviously a security concern. I found that manually installing seahorse pulls in Electron Safestorage as a dependency, and once that’s done, the keyring feature works properly with Signal.
I raised this issue on Signal Messenger’s GitHub repository, but their team responded that this is a Whonix-specific issue, and they can’t address it on their end.
In my opinion, Whonix should either include Electron Safestorage by default in the Workstation or ensure it’s installed as a dependency when Signal Messenger is installed, given how critical this is for secure key storage.
Is there a Whonix Git repository where I can report this issue directly, or will posting it here on the forum be sufficient to get it addressed?
When I ran sudo apt install seahorse in Whonix Workstation, I got this output:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
cracklib-runtime gcr gnome-keyring gnome-keyring-pkcs11 libcbor0.8 libcrack2
libfido2-1 libgcr-ui-3-1 libhandy-1-0 libpam-gnome-keyring
libpwquality-common libpwquality1 openssh-client p11-kit p11-kit-modules
pinentry-gnome3 wamerican
Suggested packages:
keychain libpam-ssh monkeysphere ssh-askpass pinentry-doc
The following NEW packages will be installed:
cracklib-runtime gcr gnome-keyring gnome-keyring-pkcs11 libcbor0.8 libcrack2
libfido2-1 libgcr-ui-3-1 libhandy-1-0 libpam-gnome-keyring
libpwquality-common libpwquality1 openssh-client p11-kit p11-kit-modules
pinentry-gnome3 seahorse wamerican
0 upgraded, 18 newly installed, 0 to remove and 0 not upgraded.
Need to get 5,717 kB of archives.
After this operation, 28.7 MB of additional disk space will be used.
This shows that gnome-keyring isn’t installed by default. However, I checked for libsecret-1-0, which Signal uses to interface with a keyring backend (i.e., for Electron’s secure storage), and confirmed it’s already installed:
[template workstation user ~]% dpkg -l | grep libsecret
ii libsecret-1-0:amd64 0.20.5-3 amd64 Secret store
ii libsecret-common 0.20.5-3 all Secret store (common files)
Signal requires both libsecret and a running keyring daemon (like GNOME Keyring) to store keys securely. Since libsecret-1-0 is present, the issue seems to be that gnome-keyring is neither installed nor running by default. Without it, Signal can’t utilize libsecret for secure key storage.
In a standard Debian GNOME install, gnome-keyring is typically included, and Signal works out of the box. In Whonix, its absence feels like a deliberate choice for a lean, security-focused system. If Signal depends on a keyring daemon that Whonix doesn’t provide by default, isn’t this a Whonix-specific configuration issue rather than an upstream problem?
I appreciate the suggestion, but I don’t think Full Disk Encryption (FDE) fully addresses this issue. FDE protects data at rest, which is valuable, but it doesn’t safeguard against runtime threats. A trojan could compromise Whonix Workstation, whether through social engineering, an unpatched zero-day exploit, or another vulnerability, and access Signal’s private keys stored in plain text in local storage. Once the system is unlocked, FDE offers no protection against such an attack. Relying solely on FDE seems insufficient when the absence of a keyring daemon leaves sensitive data exposed in a way that could be mitigated with a more secure default configuration.
If Signal can access the secrets through gnome-keyring, so can malware. It’s a bit harder to implement malware that uses the session cookie equivalent of gnome-keyring than just uploading a plain text file but still not very hard. This functionality might even already be available as a module in metasploit or malware somewhere.
You are right, but I think it applies more to a targeted attack specifically designed to extract private keys from gnome-keyring. That’s a different scenario compared to a generic trojan that gains system access and stumbles upon private keys stored in plain text as an easy bonus. The added layer of complexity with gnome-keyring at least raises the bar beyond trivial access.
Thanks a lot! Really appreciate it, looking forward to the next update.