When using KeepassXC as a libsecret provider on GNU/Linux, credentials cannot be fetched by Nextcloud

[SalutAToi]

Expected behaviour

On GNU/Linux with libsecret, when using a keychain that requires to be unlocked after login (such as a KeepassXC or Bitwarden configured to work as a keyring), retry to fetch the credentials from keychain after the keychain is manually unlocked to connect to Nextcloud

Actual behaviour

If Nextcloud is started at logon, it fails to fetch credentials the first time, as the KeepassXC database is not unlocked. It asks the user to connect again to the server as a result.
When the database is unlocked, attempting to reconnect on the Nextcloud interface reprompts the user for his credentials, as the following variable is set to false (assumed) :
2020-08-21 23:22:28:530 [ info nextcloud.gui.account.state ]: Credentials asked for "https://cloud.domain.com" are they ready? false

Steps to reproduce

1. Have a GNU/Linux install without a default keyring (such as GNOME keyring, kwallet, ...) and use KeepassXC as a libsecret provider
2. Set Nextcloud desktop to start at logon
3. Login to GNU/Linux DE/WM (Nextcloud asks for creds because it cannot access the DB as it wasn't unlocked)
4. Try to reconnect via the main Nextcloud interface after closing the connection prompt
5. Nextcloud does not try to fetch from keychain and goes straight back to asking for creds

Client configuration

Client version:
2.6.5

Operating system:
Arch Linux (up to date, latest kernel), swaywm

OS language:
French

Qt version used by client package (Linux only, see also Settings dialog):
5.15.0

Client package (From Nextcloud or distro) (Linux only):
From pacman mirrors

Logs

Logs with

• DB locked and Nextcloud starting
• DB unlocked, connection prompt closed
• Reconnection from interface
  https://gist.github.com/SalutAToi/985d9ffce00e1f9c4cf3a7ab94099d47

[camilasan]

Qt 5.15 is what you see in the Settings dialog or it is the version of qt installed in your Arch Linux?

[DPTJKKVH]

This is not limited to KeepassX but also Seahorse (default Ubuntu Keyring) if you not automatically unlock it on startup or remove the password altogether.

So maybe we could draw the scope smaller to just Nextclous failing to retry?

[SalutAToi]

Sorry, a bit late in my response

Qt 5.15 is what you see in the Settings dialog or it is the version of qt installed in your Arch Linux?

That's from the installed version of Qt, the only thing I have in the "about" section in settings is "Version 2.6.5 (Arch)"

This is not limited to KeepassX but also Seahorse (default Ubuntu Keyring) if you not automatically unlock it on startup.

Yep, it uses libsecret, wich communicates with the Secret Service API, which is used by most keychains. So I assume the problem will show up for anything that has to be unlocked manually after logon.

[blacktemplar]

I have the same problem.

A workaround for that is using the following bash script as a startup instead of nextcloud directly:

#!/bin/bash

while ! $(secret-tool lookup Title Nextcloud &> /dev/null); do
	echo "wait"
	sleep 1s
done

/usr/bin/nextcloud --background

[phoerious]

I believe this is a general Nextcloud issue. I was using Nextcloud with KWallet before KeePassXC had libsecret support and I had the same issue there, starting at some version 2.x. There is an issue somewhere on the bug tracker here about that.

[ccryx]

As far as I can tell the secret-service spec is not super clear on this issue but strongly encourages storing lookup attributes unencrypted (they "are not part of the secret") and allowing searches via these attributes. For KeePassXC at least this is apparently not desired since it can betray potentially private information when storing this data unencrypted and exposing it without unlocking the database.
A workaround - though not mandated by the spec - is to unlock prior to searching for secrets but since I don't know anything about qtkeychain I don't know how viable that is. See keepassxreboot/keepassxc#4443 for more. The Network-Manager applet behaves the same way, so while this is more of a bug/design decision in the org.freedesktop.secrets providers, it would be nice if Nextcloud could try searching again after unlocking.

[github-actions]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!