The situation of KWallet, and what to do about it?

[Thomas Pfeiffer]

On 07.07.2016 19:50, Kevin Ottens wrote:
> There's two sides to that problem in fact, use from applications and the
> service provided by our workspace.
>
> I think that for applications the answer is neither KSecretService nor
> KWallet, etc. For the goal of making it easier for our applications to be
> shipped on more platforms, what we want in fact is to port them away from
> anything platform specific to something like QtKeyChain:
> https://inqlude.org/libraries/qtkeychain.html

> This way, the actual storage becomes a workspace decision. That could keep
> being KWallet if improved, or KSecretService, or a simple D-Bus service
> wrapping libsecret... For sure it would at least simplify things on the
> KWallet/KSecretService side, they wouldn't need to be frameworks anymore
> (QtKeyChain or equivalent would play that role) just to expose a D-Bus API
> (likely the Secret Service one in the end).

Oh, indeed, that would absolutely make sense! Deploying and using applications 
which use KWallet outside of Plasma must be a pain right now.

So how do we make that happen? Deprecate the KWallet framework and recommend to 
use QtKeyChain instead, and then in parallel decide which bakcend to use for 
QtKeyChain in Plasma?

>> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-> api-0.1.html
>
> 0.1 being outdated, you probably want to link that one:
> https://standards.freedesktop.org/secret-service/

Ah yes, indeed.

> Hope that somewhat made sense and helps.

It made sense to me at least :)