| Summary: | Migrate plasma-nm to QtKeyChain | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Andreas Schneider <asn> |
| Component: | Networks widget | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | mk.mateng |
| Priority: | NOR | ||
| Version First Reported In: | master | ||
| Target Milestone: | 1.0 | ||
| Platform: | Other | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=504312 | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Andreas Schneider
2026-01-24 18:52:07 UTC
I forgot to mention that sshkeypass already uses QtKeyChain. Plasma-nm not directly supporting Secret Service (via QtKeyChain) is really the main issue in bug 504312. But 504312 focuses more on the connection problems than the migration to QtKeyChain, so I'll leave this one to focus on the migration. A few notes on your analysis: - I wouldn't recommend sharing the Secret Service DB between machines. It's designed for local use, and most client apps don't include a machine identifier in their secret keys. So there's not much use including it in the plasma-nm keys. - If plasma-nm needs to store a JSON map, it can just store the JSON string as the secret value. There's no need to change that part. - It can't use "psk" as a part of the key, since that's a selectable option that's directly related to the password. It tells plasma-nm how that password is used. So it needs to be part of the value (or a separate value in a related key). - There's no need for a manifest. Plasma-nm knows exactly which keys it needs for each connection. - The QtKeyChain API is already quite simple. It doesn't need an extra wrapper layer. - There's no need to migrate data. This is taken care of by KWallet. If you're using KWallet as the Secret Service provider, it already has the data internally, and exposes it through the Secret Service API using the QtKeyChain schema (and also via the old KWallet API). If you're using it as a proxy to a different provider, then it would have already migrated the data to there (with the same schema). You just need to make sure you're reading (and writing) the correct keys. - The fallback from Secret Service to KWallet API is handled automatically by QtKeyChain. You don't need to mess with that. Hi michaelk83,
thanks for your comments. I'm not a KDE developer and don't know the APIs like other do. I just hoped I could start some discussion and idea collection. Thanks for chiming in.
> - I wouldn't recommend sharing the Secret Service DB between machines. It's designed for local use, and most client apps don't include a
> machine identifier in their secret keys. So there's not much use including it in the plasma-nm keys.
I'm sure this is something people do and want, especially if they use a password manager which use the cloud for password storage. Probably the best would be to implement this in a kde framework to have it available in for every app. You don't want to copy and paste your password from your data base from your desktop to your notebook and vice versa. I think it is worth thinking about it :-)
It's really not up to KDE Frameworks. The Secret Service API was designed (a long time ago) on XDG, and how the client apps use it is entirely up to each individual app. Technically, I suppose you _could_ share the Secret Service DB, but even then you typically _don't_ want machine-specific keys. If your apps are connecting to the same accounts on all the machines where you share the DB, then they'd need the same passwords, stored in the same keys. And if they're connecting to different accounts, they should create separate keys for those accounts (but again - that's up to each app). In NetworkManager's case, that'd just be a separate entry for each connection, which AFAIK it already does. |