search

element-hq / element-desktop

A glossy Matrix collaboration client for desktop.
https://element.io
Apache License 2.0
1.09k stars 243 forks source link

Account gets logged out after previously failing libsecret access #1429

Open networkException opened 6 months ago

networkException commented 6 months ago

Steps to reproduce

  1. Start element-desktop on a new profile element-desktop --profile-dir=/tmp/element-testing while having a libsecret backend running and available for element to write session and seshat credentails
  2. Log into an account
  3. Close element-desktop ^C
  4. Open it again (this time blocking libsecret access which would happen over DBus) firejail --noprofile --nodbus element-desktop --profile-dir=/tmp/element-testing
  5. Close element-desktop again ^C
  6. Open it again element-desktop --profile-dir=/tmp/element-testing

Outcome

What did you expect?

I should stay logged into the account or at least view a cached version of it because credentials couldn't be retrieved from libsecret

What happened instead?

I see the login screen again, probably because libsecret failed the last time element-desktop started.

Operating system

NixOS & Debian

Application version

Element Desktop 1.11.53

How did you install the app?

nixpkgs unstable & packages.element.io/debian

Homeserver

matrix.org and selfhosted Synapse 1.98.0

Will you send logs?

Yes (these were sent from the element running as firejail --noprofile --nodbus element-desktop --profile-dir=/tmp/element-testing, as per the steps above)

networkException commented 6 months ago

This happened to me multiple times over the week and it makes desktop element pretty useless. I'm also not sure if this is actually related to libsecret, I'm usually pretty good at unlocking my libsecret backend before starting element.

I don't see how to get the session back and its extremely painful to do an initial sync and key import for multiple tens of thousands of keys every time.

t3chguy commented 6 months ago

Please report issues with community maintained packages to their maintainers

networkException commented 6 months ago

I can reproduce the same issue on debian with the package from packages.element.io.

t3chguy commented 6 months ago

Please send logs from that client then

networkException commented 6 months ago

I'm unsure how to provide relevant logs here, nothing that gets printed to stdout looks related.

I updated the reproduction steps with specific commands to run though, I hope that helps

t3chguy commented 6 months ago

image

networkException commented 6 months ago

Ok, I did that from the element running as firejail --noprofile --nodbus element-desktop --profile-dir=/tmp/element-testing, as per the steps above

j1warren commented 6 months ago

Pretty sure, it's unrelated, but got my account logged out after update.

Is it possible to do "extract keys" manually? Get it from any files in ~/.config/Element folder?

networkException commented 6 months ago

I did some more testing and it changed to this behavior in 1.11.46, .45 worked fine

emilylange commented 6 months ago

Can reproduce with the steps outlined in the opening comment with GNOME keyring as libsecret backend. I did, however, not use firejail in step 4, but rather locked my keyring again and then denied unlocking it.

The GNOME keyring usually unlocks itself on user session login of the graphical desktop/window environment. This however only works when the keyring passphrase is identical with the one used for linux user session login.

Meaning this can happen with GNOME keyring from time to time naturally, when the keyring needs interaction to unlock (e.g. because it does not unlock automatically on linux user session login) and is then denied or timing out.

Xiretza commented 3 months ago

Also happens with KeepassXC as the secret store with the Arch element-desktop package. Has been happening for a long time, confirmed still happening on 1.11.60-1. Unfortunately for me it's perfectly reproducible - I've already removed Element from autostart, but sometimes I still forget to start KeepassXC before starting Element, nuking my session and all settings...

I've submitted more logs.

networkException commented 2 months ago

I for myself have a hacky workaround until this gets fixed with which I haven't logged myself out yet:

I added a check to element's .desktop file looking something like this

secret-tool lookup service element.io | xargs test ! -z && element-desktop

so element will only start when that initial test lookup succeeds.

OdinVex commented 2 months ago

I for myself have a hacky workaround until this gets fixed with which I haven't logged myself out yet:

I added a check to element's .desktop file looking something like this

secret-tool lookup service element.io | xargs test ! -z && element-desktop

so element will only start when that initial test lookup succeeds.

That unfortunately does not loop, making autostart useless and giving you no feedback of why it won't run. I chose this instead: Exec=/bin/sh -c 'while secret-tool lookup service element.io | xargs test -z; do sleep 1; done; element-desktop --hidden' Granted, this causes it to loop until success but it sleeps, so no CPU issues at all.