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 <er...@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
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
