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

[prev in list] [next in list] [prev in thread] [next in thread] 

List: kde-panel-devel
Subject: Re: The situation of KWallet, and what to do about it?
From: valentin rusu <valir () kde ! org>
Date: 2016-07-07 20:28:17
Message-ID: DAFD0E61-BD64-47DB-B7BF-524196AF26BC () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]

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

[Attachment #5 (text/html)]

<html><head></head><body>Hello, 
 
Thanks for including this address in this thead. I&#39;m curently on the go and \
I&#39;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&#39;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. <div class="gmail_quote">On July 7, 2016 \
8:50:08 PM GMT+03:00, Kevin Ottens &lt;ervin@kde.org&gt; 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, On Thursday, 7 \
July 2016 12:36:26 CEST Thomas Pfeiffer wrote: <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 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? </blockquote> 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: <a \
href="https://inqlude.org/libraries/qtkeychain.html">https://inqlude.org/libraries/qtkeychain.html</a> 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). <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">htt \
ps://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets</a>-&gt; \
api-0.1.html </blockquote> 0.1 being outdated, you probably want to link \
that one: <a href="https://standards.freedesktop.org/secret-service">https://standards.freedesktop.org/secret-service</a>/ Hope that somewhat made sense and helps. Regards.</pre></blockquote></div></body></html>

[Attachment #6 (text/plain)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

[prev in list] [next in list] [prev in thread] [next in thread] 