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

[valentin rusu]

Hello,

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 at kde.org> wrote:
>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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160707/2c7063a3/attachment.html>