Desktop app can not use keys in keyring after it is unlocked

danielfomin96 commented 3 years ago

Description

I am using KeePassXC, which uses libsecret, as my keyring where Element-desktop stores the necessary keys for decryption. KeePassXC locks itself each time the laptop is closed which means that Element cannot read any messages after opening the laptop while I did not unlock the password manager yet. My problem is that Element can not decrypt the messages even if unlock the keyring. It seems like Element does not check for an unlock, not even periodically. This means that every time I close and open the laptop again I have to close the Element app, unlock the keyring and open Element back again. (When not unlocking the keyring before opening Element, Element requests an unlock of the keyring but does not wait for it to succeed, failing again to decrypt the messages, but that probably will be a different github issue)

Steps to reproduce

Use a keyring that uses libsecret such as KeePassXC
Unlock keyring (KeePassXC in this case)
Open Element (everything still works)
Lock keyring
Wait for about an hour (Maybe some temporary key times out) -> Element cannot decrypt messages
Unlock keyring

UPDATE (easier reproduction):
Login into Linux user account
Open Element
Shows no connectivity as keychain is still locked
Unlock keyring

At this point I expect Element to fetch the missing keys from the keyring and be able to decrypt the messages at some point of time, but it does not.

Screenshot of failed decryption

Version information

Platform: desktop
OS: Arch Linux
Version: 1.7.29

There is a relation to vector-im/element-desktop#874

ReneHollander commented 2 years ago

I cobbled together https://github.com/ReneHollander/matrix-react-sdk/commit/a6caf946c960c159be740f0039e0d836bf4bb85b to address this issue.

Not ideal as during startup Element just displays a loading circle for ever. This might be an issue if someone reset their Keyring and tries to open Element again.

mrusme commented 2 years ago

For me it seems that even if KeePassXC is unlocked, Element is not able to retrieve the key that it initially stored. After logging in for the first time and restarting the element-desktop, KeePassXC requests access for Element to its own key:

screenshot_2022-04-08-113836

When I allow, Element starts and shows me all messages as "Unable to decrypt" errors. Even though I allow access indefinitely, KeePassXC will still show this message every time I start element-desktop. This issue has come up with the latest update of Element and KeePassXC:

Element version: 1.10.7
Olm version: <not-enabled>

KeePassXC 2.7.1

Element doesn't report any issues regarding the keys in its logs:

~/.config/Element exists: yes
~/.config/Riot exists: no
[4124:0408/114714.477898:ERROR:object_proxy.cc(623)] Failed to call method: org.freedesktop.DBus.Properties.Get: object_path= /org/freedesktop/portal/desktop: org.freedesktop.DBus.Error.InvalidArgs: No such interface “org.freedesktop.portal.FileChooser”
[4124:0408/114714.477920:ERROR:select_file_dialog_impl_portal.cc(243)] Failed to read portal version property
Starting auto update with base URL: https://packages.element.io/desktop/update/
Auto update not supported on this platform
Fetching translation json for locale: en_EN
Changing application language to en-us
Fetching translation json for locale: en-us
Could not fetch translation json for locale: 'en-us' Error: Cannot find module './i18n/strings/en-us.json'
Require stack:
- /opt/Element/resources/app.asar/lib/language-helper.js
- /opt/Element/resources/app.asar/lib/tray.js
- /opt/Element/resources/app.asar/lib/electron-main.js
-
    at Module._resolveFilename (node:internal/modules/cjs/loader:940:15)
    at Function.n._resolveFilename (node:electron/js2c/browser_init:249:1105)
    at Module._load (node:internal/modules/cjs/loader:785:27)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13331)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at AppLocalization.fetchTranslationJson (/opt/Element/resources/app.asar/lib/language-helper.js:76:20)
    at /opt/Element/resources/app.asar/lib/language-helper.js:89:39
    at Array.forEach (<anonymous>)
    at AppLocalization.setAppLocale (/opt/Element/resources/app.asar/lib/language-helper.js:88:17) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/opt/Element/resources/app.asar/lib/language-helper.js',
    '/opt/Element/resources/app.asar/lib/tray.js',
    '/opt/Element/resources/app.asar/lib/electron-main.js',
    undefined
  ]
}
[4168:0408/114714.532757:ERROR:sandbox_linux.cc(377)] InitializeSandbox() called with multiple threads in process gpu-process.
Resetting the UI components after locale change
Resetting the UI components after locale change
Changing application language to en-us
Fetching translation json for locale: en-us
Could not fetch translation json for locale: 'en-us' Error: Cannot find module './i18n/strings/en-us.json'
Require stack:
- /opt/Element/resources/app.asar/lib/language-helper.js
- /opt/Element/resources/app.asar/lib/tray.js
- /opt/Element/resources/app.asar/lib/electron-main.js
-
    at Module._resolveFilename (node:internal/modules/cjs/loader:940:15)
    at Function.n._resolveFilename (node:electron/js2c/browser_init:249:1105)
    at Module._load (node:internal/modules/cjs/loader:785:27)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13331)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at AppLocalization.fetchTranslationJson (/opt/Element/resources/app.asar/lib/language-helper.js:76:20)
    at /opt/Element/resources/app.asar/lib/language-helper.js:89:39
    at Array.forEach (<anonymous>)
    at AppLocalization.setAppLocale (/opt/Element/resources/app.asar/lib/language-helper.js:88:17) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/opt/Element/resources/app.asar/lib/language-helper.js',
    '/opt/Element/resources/app.asar/lib/tray.js',
    '/opt/Element/resources/app.asar/lib/electron-main.js',
    undefined
  ]
}
Resetting the UI components after locale change

When I open the Security & Privacy preferences I see a loading circle under "Cross-signing" and nothing else. Under Advanced I see the following:

Cross-signing public keys: | not found
Cross-signing private keys: | not found in storage
Master private key: | not found locally
Self signing private key: | not found locally
User signing private key: | not found locally
Homeserver feature support: | not found

The only thing the command line log shows is:

[4168:0408/114849.527848:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!

I'm running element-desktop from the Gentoo repositories.

danielfomin96 commented 2 years ago

@mrusme This seems to be an additional problem, which can be worked around by disabling "Confirm when passwords are retrieved by clients" in the Secret Service Integration Settings of KeePassXC. At least this worked for me. Of course this work around decreases the security a little.

danielfomin96 commented 2 years ago

I would also like to point out that I did not observe the issue of this ticket anymore.

mrusme commented 2 years ago

@mrusme This seems to be an additional problem, which can be worked around by disabling "Confirm when passwords are retrieved by clients" in the Secret Service Integration Settings of KeePassXC.

Just tried this, unfortunately it doesn't help. In the Authorization tab it doesn't even seem to list element-desktop whatsoever.

I'm wondering whether this is an element-desktop bug or more like a KeepassXC issue.

danielfomin96 commented 2 years ago

Just to make sure, you don't see an electron entry in the Authorization tab as well, right? Because I see electron instead of element-desktop in this tab.

mrusme commented 2 years ago

I restarted element one more time and now I see the authorization:

screenshot_2022-04-08-121429

However, element still shows the error for every message, so it still doesn't seem to be able to retrieve the key.

mrusme commented 2 years ago

I enabled "Show notification when passwords are retrieved by clients" and I can see two dunst notifications every time I launch element, btw. So it seem that KeepassXC is allowing element to access the key and element should be able to use it.

mrusme commented 2 years ago

I tried the "Re-request encryption keys" link multiple times while having another session opened, but it won't work either. I then opened a third session and tried again but I still can't seem to retrieve any key.

Element basically seems to become completely unusable when there's an issue with the key.

I've then signed out. KeepassXC popped up, asking me for the passphrase. When I pressed enter, KeepassXC just died. It seems like it's an issue on both ends, Element as well as KeepassXC.

With KeepassXC dead I've logged in again, which worked. I authorized the session using one of the other two devices. Keys were synced.

I have restarted KeepassXC and see that Element move the previous key into the Recycle Bin. There was no new key added (probably due to the fact that KeepassXC was off when I signed back in).

I have then quit element-desktop and started it again, while KeepassXC was running. KeepassXC crashed again:

YubiKey: Failed to establish PCSC context.
YubiKey: PCSC interface is disabled or not initialized.
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
[1]    17843 segmentation fault  keepassxc

I will report this issue to KeepassXC and link this bug report as well for them to understand how this happens.

mrusme commented 2 years ago

Turns out it's a KeePassXC issue in first place. Apparently the latest version, 2.7.1, is incompatible with the database from the previous version that I used, 2.6.6.

Nevertheless, the key issue with element-desktop where it becomes unusable as soon as the key disappears should still be addressed in a way or the other. Re-requesting keys don't seem to work in that case.

t3chguy commented 2 years ago

Re-requesting keys don't seem to work in that case.

That's a different key

Olm version:

This shows that your cryptographic identity wasn't loaded so encryption is entirely disabled

mrusme commented 2 years ago

I'm running into the same issue all over again. element-desktop again can't seem to be able to read the key, even though I get the confirmation from KeePassXC. Hence, element-desktop is yet again not able to decrypt messages anymore.

I'm starting to believe it's actually a KeePassXC issue, so I will report this there as well.

mrusme commented 2 years ago

I've tested a couple of things and tried other applications as well and it seems that this is only happening with element-desktop. The first time element-desktop is run/configured, it manages to store the key in KeePassXC, however, every time after that it fails to read the content it retrieves from KeePassXC. I've double checked with the KeePassXC project and made sure element-desktop can actually access the key, which it seems it can.

Hence contrary to my initial belief, I'm starting to think that it is an element-desktop issue, in fact. I can't reproduce this issue in any other application.

dbkr commented 2 years ago

I've put X-Needs_investigation on this as it looks like the original bug is not really an accurate description of the problem anymore.

mrusme commented 2 years ago

I've tried setting up Element from scratch, logging in and not unlocking the keychain so that Element simply won't store its key in KeepassXC. This worked for the first launch, but as soon as I quit Element and re-launched it, everything is broken to a point that it can't even connect to the server anymore. As a matter of fact Element is unusable for me right now on the desktop unfortunately.

mrusme commented 2 years ago

I've upgraded to the following version of Element:

Element version: 1.10.11
Olm version: 3.2.8

It looks like now Element is trying to get the key from KeepassXC but ultimately fails (I assume, because I reset it and it has no key stored there) and will resort to... idk exactly what key. However, it is working now at least. Element starts up and I can read all messages. It seems that it stores its key somewhere else:

Backup key stored: | in secret storage
-- | --
Backup key cached: | not found locally
Secret storage public key: | in account data
Secret storage: | ready
Backup version: | 1
Algorithm: | m.megolm_backup.v1.curve25519-aes-sha2

t3chguy commented 2 years ago

The key stored in your key chain is the pickle key, there's no ui to view its state, only the console logs. That key is used to pickle all other keys in IDB and also another key is to encrypt Seshat. So the app keys are still being stored, just now in plaintext on your disk.

bodqhrohro commented 1 year ago

So the app keys are still being stored, just now in plaintext on your disk

@t3chguy so how to make use of them explicitly?

I had already glanced over this issue before creating my one, and I don't quite get why do you consider it the same issue actually, as OP's keys were initially stored in a keyring, while my keys were not.

t3chguy commented 1 year ago

@bodqhrohro your logs show a

2023-04-03T17:23:02.628Z I EventIndex: Error initializing the event index {"message":"Error opening the database: DatabaseUnlockError(\"Invalid passphrase\")"}

Have you tried just clicking reset under Message Search to reinitialise it? If it doesn't work without a keyring then I suggest an issue in https://github.com/matrix-org/seshat/

bodqhrohro commented 1 year ago

It's "just" for you, as I had a pretty large room which was cached for several hours on LTE last time, with a script holding PgUp all this time…

Anyway, I tried to reset it with a keyring opened, and now element-desktop just crashes soon after the start with SIGTRAP. gdb just shows a long chain of 0xaaaaaaaaaaaaaaaa addresses. Totally not sure how to debug it now.

t3chguy commented 1 year ago

There are multiple issues about sigtraps already open

element-hq / element-desktop