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

[Thomas Pfeiffer]

On 11.07.2016 22:29, Mark Gaiser wrote:
> On Mon, Jul 11, 2016 at 9:58 PM, Thomas Pfeiffer <thomas.pfeiffer at kde.org 
> <mailto:thomas.pfeiffer at kde.org>> wrote:
>
>     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?
>
>
> I don't get that. How is deprecating KWallet paves the way to make something 
> new with QtKeyChain?

Of course deprecating KWallet alone does not do anything, but I think it will be 
necessary to "motivate" application developers to port away from it.

> As far as i can tell, QtKeyChain isn't a keychain at all, it's a wrapper 
> around platform specific keychains that provides a unified interface for 
> keychain functionality. It itself doesn't implement a keychain (or it does on 
> windows?).

Yes, QtKeychain wraps available keychains from the platform it runs on.
However: "Since Windows does not provide a service for secure storage QtKeychain 
uses the Windows API function CryptProtectData to encrypt the password with the 
user’s logon credentials. The encrypted data is then persisted via QSettings."

On Linux we could use GNOME Keyring, but if we don't want that, we'd of course 
still have to implement our own backend. The advantage would be that it would be 
much easier to replace that at any point without having to adapt applications.

>
> Or do you mean deprecating/removing the *graphical* KWallet part and 
> re-implementing that in top of QtKeyChain?

Yes, that's what I mean.
>
> Using QtKeyChain would be interesting imho. Specially if that itself is 
> extended to use other web backends as keychain.

Yes, that would be great!