element-desktop fails to launch in a jail when dbus is disabled

[aral-matrix]

Steps to reproduce

1. Where are you starting? What can you see?

env DBUS_SESSION_BUS_ADDRESS=none firejail --noprofile --private=~/.firejail element-desktop

-> element-desktop launches, but fails to recognize the active session:
Failed to load database
Clear data and reload?
Unable to access secret from system keyring, it appears to have changed.

2. What do you click?

If this dialog is confirmed with "yes", it wipes the active session from the jail and still fails to launch. Selecting "No" will of course terminate the application

3. More steps…

Starting element-desktop without disabling DBUS works fine:

firejail --noprofile --private=~/.firejail element-desktop

Using DBUS is not a solution, because DBUS itself is a security liability, in that it allows a jailed application to access services outside the jail - and additionally, when file dialogues are concerned, it creates an intransparency for the user as to whether a jailed application sees their home folder only thanks to DBUS, or whether they (accidentally) launched the application outside a jail.

Element-desktop worked fine without DBUS until ca. 1 1/2 years ago, and then the changed authentication system broke that. Please reimplement support that does not require DBUS.

Outcome

What did you expect?

I expect element to launch without dbus

What happened instead?

Element fails to launch without dbus

Operating system

Linux 6.1.0-40-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.153-1 (2025-09-20) x86_64 GNU/Linux

Application version

Element version: 1.12.3

How did you install the app?

packages.element.io/debian

Homeserver

matrix.org

Will you send logs?

No

[t3chguy]

Please reimplement support that does not require DBUS.

We use Electron's https://www.electronjs.org/docs/latest/api/safe-storage as the alternative (keytar) was no longer maintained and a ticking time bomb for security vulnerabilities, I suggest opening an issue with Electron as we are not going to be rolling our own native node modules for keyring/secure enclave access on each of macOS, Windows, Linux due to lack of staffing to maintain such securely

[aral-matrix]

So - do I get this right? It was the electron framework that broke the functionality which now requires DBUS to work?

Assuming (I can suspect how this goes) they won't do anything about it: Could element provide a configuration option that completely disables "safe storage"? I don't need it, don't use it, and probably never will for private purposes.

[t3chguy]

As per my earlier statement, we switched from the no-longer-maintained node-keytar https://github.com/atom/node-keytar to the supported Electron safeStorage, the latter of which may require dbus depending on which implementation it connects to, that is not well documented.

Could element provide a configuration option that completely disables "safe storage"?

There is an Element config safeStorageBackend: "plaintext" or there is a command line arg you can pass --storage-mode=force-plaintext, as well as Chromium CLI params like --password-store

[aral-matrix]

There is an Element config safeStorageBackend: "plaintext" or there is a command line arg you can pass --storage-mode=force-plaintext

You know what - as unexpected as that was, this actually solves my problem. I suppose it would be nice to have this option displayed somewhere prominently when the safe-storage thing fails, as a "in case you do not want to use safe-storage, you can use --storage-mode=force-plaintext to run the application anyways, at your own risk.

I am not sure where to suggest to document this prominently enough that people like me to not reluctantly run element with DBUS enabled for 1 1/2 years (or mostly not at all), but my "bug report" is in this case not a bug report, but a feature request and that feature is already available, so you can close the issue :)

Thank you for the quick response & providing a solution!

[aral-matrix]

For reference: electron/electron#48935