Secret service prompts to create a new database when used via kwalletd

[rocketraman]

Have you searched for an existing issue?

• Yes, I tried searching and reviewed the pinned issues

Brief Summary

I use the KeepassXC secret service integration on Linux. KeepassXC is opened and the database that shares the group attached to the secret service is unlocked.

However, when an app that uses the KDE wallet interface to access the secret service attempts to access a secret, KeepassXC pops open a "Create a new KeePassXC database..." dialog box.

I used dbus-monitor --session "interface='org.freedesktop.Secret.Service'" to check the dbus activity while this secret access was happening, and I see this (:1.115 and :1.124 are kwalletd6) :

method call time=1764371496.813357 sender=:1.115 -> destination=org.freedesktop.secrets serial=10613 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=ReadAlias
   string "default"
method call time=1764371497.712482 sender=:1.115 -> destination=org.freedesktop.secrets serial=10616 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=ReadAlias
   string "default"
method call time=1764371497.713728 sender=:1.124 -> destination=org.freedesktop.secrets serial=48786 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=CreateCollection
   array [
      dict entry(
         string "org.freedesktop.Secret.Collection.Label"
         variant             string "passwords"
      )
   ]
   string ""

My database has a name, so this is not the same as #12316.

What is interesting is that when KeepassXC is first started, there is no OpenSession command sent from kwalletd6 to KeepassXC. The only thing shown in dbus is:

signal time=1764372223.336522 sender=:1.4111 -> destination=(null destination) serial=49 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=CollectionCreated
   object path "/org/freedesktop/secrets/collection/passwords"
signal time=1764372229.668954 sender=:1.4111 -> destination=(null destination) serial=64 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=CollectionChanged
   object path "/org/freedesktop/secrets/collection/passwords"
signal time=1764372229.850297 sender=:1.4111 -> destination=(null destination) serial=69 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=CollectionChanged
   object path "/org/freedesktop/secrets/collection/passwords"

There appears to be two workarounds to this:

1. Use secret-tool to interact with the secret service directly. When doing this the dbus monitor shows:

method call time=1764371666.205677 sender=:1.4095 -> destination=:1.4052 serial=9 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=OpenSession

and thereafter accesses from tools that use the KDE wallet also work correctly. I'm not super-familiar with dbus and kwallet but its interesting to me that OpenSession used by a different tool fixes kwalletd6 access as well.

2. In KeepassXC, explicitly turn off the secret service integration and then turn it back on again. When the integration is turned on again, I see this in the dbus monitor, noting the OpenSession specifically:

method call time=1764371942.644143 sender=:1.124 -> destination=:1.4105 serial=56917 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=OpenSession
...
method call time=1764371942.836046 sender=:1.115 -> destination=org.freedesktop.secrets serial=10806 path=/org/freedesktop/secrets; interface=org.freedesktop.Secret.Service; member=ReadAlias
   string "default"

As noted above, 124 and 115 are the kwalletd6 application:

So it seems that when KeepassXC registers itself as a secret service provider after initial start, kwallet opens its session. But when KeepassXC is initially started, whatever triggers kwalletd6 to use the OpenSession method does not happen. And if secret-tool is used and runs OpenSession, then subsequent accesses from kwalletd6 are also fine.

Also note that if KeepassXC is restarted, access breaks again until one of the above workarounds is again applied.

Steps to Reproduce

On KDE/Wayland (see versions I am using below)

3. Enable the secret service in KeepassXC
4. Restart KeepassXC
5. Attempt to access a secret via kwalletd. Anything Chromium based e.g. Chrome/Slack/Discord/etc. is a good test. Jetbrains Toolbox works also. This access will fail and cause the "Create a new KeePassXC database..." dialog to pop open. The calling app fails to retrieve its secret and continues on without it.

Expected Versus Actual Behavior

No response

KeePassXC Debug Information

KeePassXC - Version 2.7.11
Revision: 6a2ed32

Qt 5.15.18
Debugging mode is disabled.

Operating system: Fedora Linux 43 (Forty Three)
CPU architecture: x86_64
Kernel: linux 6.17.8-300.fc43.x86_64

Enabled extensions:
- Auto-Type
- Browser Integration
- Passkeys
- SSH Agent
- KeeShare
- YubiKey
- Secret Service Integration

Cryptographic libraries:
- Botan 2.19.5

Operating System

Linux
Kernel Version: 6.17.8-300.fc43.x86_64 (64-bit)

Linux Desktop Environment

KDE
Operating System: Fedora Linux 43
KDE Plasma Version: 6.5.3
KDE Frameworks Version: 6.20.0
Qt Version: 6.10.0

Linux Windowing System

Wayland

[droidmonkey]

See #7839 as well

[rocketraman]

See #7839 as well

Yeah, I saw #7839 but I noted from the comments it was not the same issue at all. From #7839 (comment) by @Aetf .

Thanks for the output. In the log, the error was the "default" alias not found. Thus the program went ahead to try to create one.

Have you exposed a group to the secret service after creating the new database? By default, no groups or entries are exposed via the secret service for security reasons.

In my case, I do expose a group to the secret service and the default alias is present (confirmed via a dbus query).

[michaelk83]

Since you've confirmed your default alias is present, my best guess is https://bugs.kde.org/show_bug.cgi?id=512135 (see also #12445). But your workarounds are pointing somewhere else. By default, KWallet creates a kdewallet collection. I think it should still work as long the default alias exists, but maybe your different collection name confuses it somehow.