AFAIK, plasma-nm doesn't have code to use Secret Service directly. It's one of the KDE apps that need to be migrated to QtKeyChain (which can use both Secret Service and old KWallet APIs).

Until that's implemented, the other part here is to make sure that the kwalletd proxy is working correctly (it may not be).

Now that we have a few more users here, it would be good to get some DBus traces, so we can check if kwalletd is at fault. The relevant interfaces are org.kde.kwalletd6 , org.kde.KWallet , org.freedesktop.secrets , and org.kde.secretservicecompat . Or you could filter by path: /modules/kwalletd6 , /org/freedesktop/secrets , and /ksecretd .

It would also be good to see your kwalletrc, to check that everything is configured correctly (or to see how different configurations affect the behavior).

One ting i noted while using keepassXC is that every entry in the wallet is separatedly locked, but what should happen in that case is keepassxc popping up with some gui to unlock when networkmanager tries to access the network

(In reply to michaelk83 from comment #2)
> Now that we have a few more users here, it would be good to get some DBus
> traces, so we can check if kwalletd is at fault. The relevant interfaces are
> org.kde.kwalletd6 , org.kde.KWallet , org.freedesktop.secrets , and
> org.kde.secretservicecompat . Or you could filter by path:
> /modules/kwalletd6 , /org/freedesktop/secrets , and /ksecretd .
> 
> It would also be good to see your kwalletrc, to check that everything is
> configured correctly (or to see how different configurations affect the
> behavior).

For me, this is the kwalletrc:

[KSecretD]
Enabled=false

[Migration]
MigrateTo3rdParty=true
WalletsMigratedToSecretService=kdewallet

[Wallet]
Close When Idle=false
Close on Screensaver=false
Default Wallet=Passwörter
Enabled=true
First Use=false
Idle Timeout=10
Launch Manager=false
Leave Manager Open=false
Leave Open=true
Prompt on Open=false
Use One Wallet=true

[org.freedesktop.secrets]
apiEnabled=true

And i'll add the DBus Traces as attachment.

Created attachment 181492 [details]
DBus traces of entering WiFi password (password removed from traces)

(In reply to Marco Martin from comment #3)
> One ting i noted while using keepassXC is that every entry in the wallet is
> separatedly locked, but what should happen in that case is keepassxc popping
> up with some gui to unlock when networkmanager tries to access the network

That's a good point, but one of the problems with that is that not all the relevant API methods support the Prompt interface. However, KeepPassXC may still try to show an unlock prompt to avoid some other problems. In that case, the call can still time out.
See https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/101 and https://github.com/keepassxreboot/keepassxc/issues/4443

To avoid that, clients should never use `Collection.SearchItems()` with KeePassXC (`Service.SearchItems()` at least has a `locked` output array), and, if possible, should issue an explicit `Unlock()` call before trying any other operations.

(In reply to turtoise from comment #5)
> Created attachment 181492 [details]
> DBus traces of entering WiFi password (password removed from traces)

Thanks!

What I see from this trace, is:
A. The network manager is talking to the old KWallet API (and not directly to Secret Service), as expected currently.
B. More `folderUpdated` signals than I'd expect to see, for a bunch of unrelated folders. Might indicate some issue or weird behavior, but probably not related to this bug.
C. There are a few attempts to save a password (writeMap), and what looks like one attempt to read it back (readMap), but without the `method return` bits, its hard to tell if any of these are successful or not.

I don't see any communication between KWallet and KeePassXC's Secret Service. That's probably due to the trace filter.

What I would like to see is the part where plasma-nm is trying (and failing) to read the stored password, including the communication between KWallet and KeePassXC, and with the method return values as well.

Trying to reproduce i didn't manage to reproduce the problem

in KeepassXC i do get an entry for each wifi network, in the form "Network Management/{UUID such as 07ea43b2-......}/802-11-wireless-security"  each of them contains a value of type {"psk": "pass..."}

NetworkManager seems to be able to access those entries just fine and seems to just work.

Is by change all normal preshared keys or is more complicated wifi authentication methods?

(In reply to michaelk83 from comment #6)
> (In reply to Marco Martin from comment #3)
> > One ting i noted while using keepassXC is that every entry in the wallet is
> > separatedly locked, but what should happen in that case is keepassxc popping
> > up with some gui to unlock when networkmanager tries to access the network
> 
> That's a good point, but one of the problems with that is that not all the
> relevant API methods support the Prompt interface. However, KeepPassXC may
> still try to show an unlock prompt to avoid some other problems. In that
> case, the call can still time out.
> See https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/101 and
> https://github.com/keepassxreboot/keepassxc/issues/4443
> 
> To avoid that, clients should never use `Collection.SearchItems()` with
> KeePassXC (`Service.SearchItems()` at least has a `locked` output array),
> and, if possible, should issue an explicit `Unlock()` call before trying any
> other operations.

searching is fine, it will get the names and the metadata of the locked value just fine, it will just need an explicit unlock when trying to actually retrieve the secret, which we do. when this happens, i see that for me keepassxc pops up with an authorization dialog

(In reply to Marco Martin from comment #8)
> Trying to reproduce i didn't manage to reproduce the problem
> 
> in KeepassXC i do get an entry for each wifi network, in the form "Network
> Management/{UUID such as 07ea43b2-......}/802-11-wireless-security"  each of
> them contains a value of type {"psk": "pass..."}
> 
> NetworkManager seems to be able to access those entries just fine and seems
> to just work.

Actually, for me it's the same behaviour, KeePassXC is updating the Network Management Key correctly. But my system does not seem to ask KeePassXC for the keys so for me it may be a configuration problem only.

(In reply to turtoise from comment #10)
> Actually, for me it's the same behaviour, KeePassXC is updating the Network
> Management Key correctly. But my system does not seem to ask KeePassXC for
> the keys so for me it may be a configuration problem only.

if you go in the kwallet systemsettings page, is the "default wallet" set to the one where the password is actually saved?

(In reply to michaelk83 from comment #2)
> Now that we have a few more users here, it would be good to get some DBus
> traces, so we can check if kwalletd is at fault. The relevant interfaces are
> org.kde.kwalletd6 , org.kde.KWallet , org.freedesktop.secrets , and
> org.kde.secretservicecompat . Or you could filter by path:
> /modules/kwalletd6 , /org/freedesktop/secrets , and /ksecretd .
> 
> It would also be good to see your kwalletrc, to check that everything is
> configured correctly (or to see how different configurations affect the
> behavior).

I'm also running into issues on my notebook with Fedora 42. How exactly do I trace dbus?

I can open kwallet, and if I open a password in kwallet, keepassxc asks me if kwallet is allowed to read the password. Also my mailtransport passwords are there and work just fine.

However with plasma-nm I'm not able to store a password. I also don't get any popups anymore.

This is really strange. However I don't really know how to debug it and help would be very welcome.