Move KWallet to its own plugin backend

[jaraco]

In #391, we learned that the presence of the KWallet backend can cause undesirable behaviors in an environment where KWallet is present but unwanted.

To address this concern, I'd like to consider:

• Move kwallet to its own backend (keyrings.kwallet probably).
• Remove it from keyring.
• Give it a higher priority (so if the user installs it, it takes precedence over SecretService).

[jaraco]

@mitya57 I'd be particularly interested in your opinion on this proposal. I rarely use keyring on Linux, so I don't have a good sense of what the best use-cases are.

Some assumptions I make:

• This change would be disruptive (and backwards-incompatible), especially for KWallet users, and especially for those users who have explicitly configured that keyring (as its name would change).
• Users who opt in to KWallet (by installing the plugin) would also be opting out of other backends (unless explicitly configured).
• Users could opt out of KWallet by uninstalling the plugin.
• Most users on Linux should prefer the SecretService backend unless they're specifically running KDE.

Can users of KDE still use SecretService to access the KWallet? Does that not imply that KWallet should be deprecated in favor of SecretService as a unified approach?

[mitya57]

The assumptions are mostly correct. The only problem I see is discoverability: users will need to know that they should install a separate package to get KWallet integration. Perhaps you can mention that in the message issued by fail keyring (that message already mentions keyrings.alt)?

keyring/keyring/backends/fail.py

Lines 20 to 23 in c0ec24c

	"No recommended backend was available. Install a recommended 3rd "
	"party backend package; or, install the keyrings.alt package if "
	"you want to use the non-recommended backends. See "
	"https://pypi.org/project/keyring for details."

About “most users on Linux”: I think most of users are using a GNOME-based desktop (GNOME itself, Cinnamon, MATE, Unity, etc). Those desktops have gnome-keyring which supports Secret Storage. Second place is KDE which has KWallet. There are also desktops which don't have any built-in password manager (Xfce, LXDE, etc) — users of these desktops would probably either install gnome-keyring or use a file-based backend.

This was my own estimation. Looking at the numbers, I can say that 43% of users who participate in Debian's popularity contest have gnome-keyring installed, and 17% have KWallet installed:

• https://qa.debian.org/popcon.php?package=gnome-keyring
• https://qa.debian.org/popcon.php?package=kwallet-kf5

Can users of KDE still use SecretService to access the KWallet? Does that not imply that KWallet should be deprecated in favor of SecretService as a unified approach?

Unfortunately KWallet does not support Secret Storage specification. Some years ago there was an attempt to develop a new application, KSecrets, that will be a successor to KWallet, but its development has stopped:

https://invent.kde.org/utilities/ksecrets/-/commits/master/

So no, for KDE users we should keep a KWallet backend.

[frispete]

I'm not sure, I follow you here @jaraco .

Just because keyring got a new feature, a keyring chainer, that behaves suboptimal in some real world scenarios, you want to exclude a proved to be useful element of keyring?

Users will stumble upon this issue, and some will even fetch the new kwallet backend, others will complain. Something, that worked well for a long time is now failing at this point. You push the burden on them. But for what reason? A keyring chainer? From a usability perspective, a user usually wants one and exactly one keyring. Chaining keyrings is a pretty esoteric feature, that is mostly useful for some very special conditions. Isn't this a very good reason to externalize the chainer instead?

[jaraco]

Thanks Frispete for the feedback and concerns. I do take them seriously.

My motivation for suggesting to move it to a third-party backend was to make it easier for users to opt in our out of the behavior because it's a keyring that's not clearly designated by the environment (compared to the clarity on macOS or Windows).

Chaining keyrings is a pretty esoteric feature, that is mostly useful for some very special conditions. Isn't this a very good reason to externalize the chainer instead?

I think you may be right here, and that's certainly worthy of consideration. Early implementations had special consideration in core, but the current implementation is largely independent. It was my initial instinct that it should be a third-party package, but ultimately settled on the current approach. I don't think externalizing that backend obviates the motivations for KWallet described herein.

[jaraco]

Based on the 17% number listed above, that seems like a large-enough number that KDE support should be included by default. If that number would fall below 10%, I'd consider it fringe enough to be a secondary package.