plasma-framework is "ported" with https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/376

Port akonadi dav ressource to QtKeychain: https://invent.kde.org/pim/kdepim-runtime/-/merge_requests/60 I'm going to take care of the google groupware too soon

I tried porting Plasma and hit some major brick walls:

Key difference.

KWallet is in the form of "folder" "appID" "key"

Where folder is in generally a preset like: Wallet::Wallet::FormDataFolder()

QtKeychain has one string: "service" which maps to both folder and appId.

: QDBusPendingCall( iface->readEntry( walletHandle, q->service(), key, q->service() ) );

This is fine for new code, but makes porting code going regress at finding existing entries.

We will either need a patch in QtKeychain to solve this, or some intense kwallet migration.

KWallet::isEnabled

This is used all over the shop. There's nothing really equivalent publicly. Internally we do have static detectKeyringBackend methods, but it always returns something.
In part it's because QtKeyring has an insecure fallback available, but it's still going to be difficult to port.

KWallet::isEnabled is for users who don't trust KWallet, right? But then what? They are prompted for a password every single time they check mail / connect to a chat / open a webpage with auth / do anything else that require authentification, right? I'm wondering if this is really workable and if anyone actually disables KWallet. Well, maybe very occasional KDE users which only use a few apps that rarely ask for auth....

This raises a few questions:

• When using QtKeychain for the first time, I assume the KWallet creation dialog shows up, what happens if the user cancels it and checks the option to disable KWallet?
• Should QtKeychain maybe expose "the user didn't want it"? Or is that the case where it currently falls back to an insecure solution? That's the worst possible outcome, especially for people don't trust KWallet to be secure enough.

I was also thinking of a KConfig entry for "don't use QtKeychain", but where would the user get a GUI to make that choice.... global KCM? a bit too centralized...

(in your last sentence you say QtKeyring but I assume you meant QtKeyChain?)

KWallet::isEnabled is for users who don't trust KWallet, right? But then what?

The check is used before that, mostly for disabling various UI elements that say "save to wallet".

The two cases I looked at were drkonqi and plasma-networkmanager. Drkonqi is hopefully used rarely enough that asking to login again isn't too bad. For plasma-nm we already have to present the user between saving locally via kwallet, or globally so that it can be used by all users using some credential storing built into networkmanager. This check hides the local option.

Worth mentioning in this thread xdg-desktop-portal now has secret support:
https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.Secret

We don't have an implementation in Qt Keychain yet but it would be trivial. One killer aspect is the appId will be fixed, and be based on the ID of the built sandbox. Effectively meaning QtKeyChain's setService will no-op.

btw with the migration to QtKeyChain and KWallet having org.freedesktop.secret support added, we should probably deprecate the KWallet API or at least make it a porting aid for KF6, since maintaining it for KF6 doesn't seem very viable

I tried porting Plasma and hit some major brick walls:

Key difference.

KWallet has a "folder" and "appID" "key"

I did some more investigation into kwallet and it turns out I was completely wrong!
kwallet does have an appId key, but it's not put into the storage anywhere. It's effectively safe to completely ignore.

I apologise for the noise, but at least it unblocks everything \o/

KWallet has a distinction between LocalWallet and NetworkWallet. By default they are the same, with an option in the KCM for "Different wallet for local passwords". QtKeychain doesn't have such a distinction and always uses the network wallet