Web lists-archives.com

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


Thanks for including this address in this thead. I'm curently on the go and I'll try to quicly reply here.

I confirm that I do not curently have lots of time and also there are all these KWallet problems that are built-in and require rewriting. You did a great job enumerating them here. Also, these last years we saw lots of others options out-there, questioning the very idea of implementing something like ksecretservice. I won't enumerate the options here but those listed by Kevin are only a subset of them. So, yeah, we should ask ourselves if we need a special password handling utility, and force users of some web-compatible solution out-there to adopt ours in addition to their preferred one.

On July 7, 2016 8:50:08 PM GMT+03:00, Kevin Ottens <ervin@xxxxxxx> wrote:

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:

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:

Hope that somewhat made sense and helps.