
<html><head></head><body>Hello,<br>

<br>

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

<br>

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

<br><br><div class="gmail_quote">On July 7, 2016 8:50:08 PM GMT+03:00, Kevin Ottens <ervin@kde.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Hello,<br /><br />On Thursday, 7 July 2016 12:36:26 CEST Thomas Pfeiffer wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> I'm addressing both the Plasma team and kde-devel because this issue affects<br /> Plasma as well as many applications, and Valentin as the current maintainer<br /> of KWallet as well as KSecretService, a potential replacement for it.<br /> <br /> KWallet plays a central role in Plasma and many KDE applications as the<br /> central password storage. However, it being very old and not having been<br /> actively developed for a long time, it has lots of problems, including:<br /> <br /> - It has weak security, as it does not restrict applications accessing it by<br /> default, and even when it does, it does so simply based on application name<br /> which allows any malicious process to impersonate an allowed one<br /> - The initial setup has huge usability

problems, as it forces users to make<br /> a choice on a very advanced technical level (encryption methods, no less!),<br /> and the option it suggests (GPG) is a nightmare to set up for ordinary<br /> users - It does support unlocking via PAM, but does not tell users what<br /> they need to do to make that work, which results in most users having to<br /> enter the KWallet password at each system start, which many find very<br /> annoying (we get lots of negative feedback for that)<br /> - It works only with KDE Frameworks-based applications<br /> - One cannot easily write a QML GUI for it, making it unsuitable for mobile<br /> <br /> Valentin has been working on KSecretService for quite a while, which is<br /> based on the freedesktop Secrets API [1] that is also supported in GNOME<br /> Keyring, and would solve many (and ideally all) of the above problems.<br /> However, Valentin told me he does not have the time to work on<br /> KSecretService any more.<br /> <br /> This means

we have to find a solution to these problems. The options I see<br /> currently are<br /> - Improve KWallet (unlikely to fix all the problems without massive changes<br /> in it, though)<br /> - Find someone to finish and maintain KSecretService<br /> - Build a wrapper around one of the other existing keyring technologies<br /> - Each application (and each Plasma component that stores passwords)<br /> implements its own encrypted password storage<br /> - We make encrypted password storage optional and non-default (easiest<br /> solution, but not exactly in line with KDE's vision)<br /> <br /> So, what do we do?<br /></blockquote><br />There's two sides to that problem in fact, use from applications and the <br />service provided by our workspace.<br /><br />I think that for applications the answer is neither KSecretService nor <br />KWallet, etc. For the goal of making it easier for our applications to be <br />shipped on more platforms, what we want in fact is to port them away

from <br />anything platform specific to something like QtKeyChain:<br /><a href="https://inqlude.org/libraries/qtkeychain.html">https://inqlude.org/libraries/qtkeychain.html</a><br /><br />This way, the actual storage becomes a workspace decision. That could keep <br />being KWallet if improved, or KSecretService, or a simple D-Bus service <br />wrapping libsecret... For sure it would at least simplify things on the <br />KWallet/KSecretService side, they wouldn't need to be frameworks anymore <br />(QtKeyChain or equivalent would play that role) just to expose a D-Bus API <br />(likely the Secret Service one in the end).<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> <a href="https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets">https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets</a>-> api-0.1.html<br /></blockquote><br />0.1 being outdated, you

probably want to link that one:<br /><a href="https://standards.freedesktop.org/secret-service">https://standards.freedesktop.org/secret-service</a>/<br /><br />Hope that somewhat made sense and helps.<br /><br />Regards.</pre></blockquote></div></body></html>