Web lists-archives.com

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

thanks for raising this topic!

2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer <thomas.pfeiffer@xxxxxxx>:
> Hi everyone,
> 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)

I disagree on this point. Even if KWallet were free of usability
issues, it would still provide a false sense of security. The user
thinks that his/her passwords are safe, while in fact they are not.
If we don't have enough manpower to develop and mantain a proper
keychain in Plasma, we should tell our users. This way they can make
sure that, for example, the unsafely stored Wi-Fi passphrase is not
used for other accounts. This is already closer to our vision than the
current situation.

My vote is: we either do it right, or we give up. If someone steps up
to fix this problem, great. Otherwise we should start to slowly port
away from KWallet.

> So, what do we do?
> Cheers,
> Thomas


> https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-api-0.1.html