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

[Kevin Ottens]

Hello,

On Thursday, 7 July 2016 12:36:26 CEST Thomas Pfeiffer wrote:
> I'm addressing both the Plasma team and kde-devel because this issue affects
> Plasma as well as many applications, and Valentin as the current maintainer
> of KWallet as well as KSecretService, a potential replacement for it.
> 
> KWallet plays a central role in Plasma and many KDE applications as the
> central password storage. However, it being very old and not having been
> actively developed for a long time, it has lots of problems, including:
> 
> - It has weak security, as it does not restrict applications accessing it by
> default, and even when it does, it does so simply based on application name
> which allows any malicious process to impersonate an allowed one
> - The initial setup has huge usability problems, as it forces users to make
> a choice on a very advanced technical level (encryption methods, no less!),
> and the option it suggests (GPG) is a nightmare to set up for ordinary
> users - It does support unlocking via PAM, but does not tell users what
> they need to do to make that work, which results in most users having to
> enter the KWallet password at each system start, which many find very
> annoying (we get lots of negative feedback for that)
> - It works only with KDE Frameworks-based applications
> - One cannot easily write a QML GUI for it, making it unsuitable for mobile
> 
> Valentin has been working on KSecretService for quite a while, which is
> based on the freedesktop Secrets API [1] that is also supported in GNOME
> Keyring, and would solve many (and ideally all) of the above problems.
> However, Valentin told me he does not have the time to work on
> KSecretService any more.
> 
> This means we have to find a solution to these problems. The options I see
> currently are
> - Improve KWallet (unlikely to fix all the problems without massive changes
> in it, though)
> - Find someone to finish and maintain KSecretService
> - Build a wrapper around one of the other existing keyring technologies
> - Each application (and each Plasma component that stores passwords)
> implements its own encrypted password storage
> - We make encrypted password storage optional and non-default (easiest
> solution, but not exactly in line with KDE's vision)
> 
> So, what do we do?

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).

> 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/

Hope that somewhat made sense and helps.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160707/a8931a70/attachment.sig>