The situation of KWallet, and what to do about it?
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) So, what do we do? Cheers, Thomas https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-api-0.1.html
Re: The situation of KWallet, and what to do about it?
On Thursday, July 7, 2016 12:36:26 PM CEST Thomas Pfeiffer wrote: > 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 Adding some more: - kwallet dialog allows keyloggers on X11 (in defence of KWallet, I only know of pinentry which handles this properly at the cost of severely degraded user experience) - kwallet does not protect against ptrace (I didn't add the protection, due to the keylogger rendering it point less) - kwallet dialog windows sometimes are placed at the bottom of the stack due to focus stealing prevention (this happens for example with akonadi/other daemons) - kwallet shows total giberish like "kded requested to open the wallet" - if one doesn't unlock the wallet fast enough applications start asking for the password. So getting a coffee while desktop starts results in thousands of password windows. > > 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 how much work is still needed? > - 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) For Plasma I would like to see unlocking the wallet integrated into the desktop shell in some way. That would fix problems like the incorrect stacking order and we can easily protect against keyloggers, etc. Especially on Wayland I would like KWin having more control of entering passwords (KWin should know that a password is entered and make it impossible to steal focus then). Cheers Martin Now going to use the secure pinentry, by clicking send signature.asc Description: This is a digitally signed message part.
Re: The situation of KWallet, and what to do about it?
Hi, thanks for raising this topic! 2016-07-07 12:36 GMT+02:00 Thomas Pfeiffer : > 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 Cheers, Elvis > > > https://www.freedesktop.org/wiki/Specifications/secret-storage-spec/secrets-api-0.1.html
Re: The situation of KWallet, and what to do about it?
In data giovedì 7 luglio 2016 13:17:12 CEST, Martin Graesslin ha scritto:
Hello Martin,
> Adding some more:
[...]
I think we should not forget that there's kwallet (the framework) and
kwallet{manager} (the frontend).
I also think that Kwallet is very much ingrained in a lot of KDE software, so
that rules out (IMO) the option for a drastic change there. I do believe, as
Thomas stated, that we *need* to have a wallet available in the workspace.
That said, some review would be in order in particular with regards to the
encryption used (see the recent breakage that occurred "just" fixing a compiler
warning).
(FYI, I'm using Kwallet with a GPG-based YubiKey, but I agree this is *not* an
acceptable, or easy enough, solution for our userbase),
> - if one doesn't unlock the wallet fast enough applications start asking for
> the password. So getting a coffee while desktop starts results in thousands
This is no longer the case, IIRC dfaure has raised the timeout to 45 minutes.
> For Plasma I would like to see unlocking the wallet integrated into the
> desktop shell in some way. That would fix problems like the incorrect
That would mean probably having Plasma providing a sort of "frontend" to the
framework? To be honest, I have no idea if there's any separation of GUI and
wallet layers in the kwallet-framework code.
--
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: A29D259B
signature.asc
Description: This is a digitally signed message part.
[ANNOUNCE] CMake 3.6.0 available for download
I am proud to announce that CMake 3.6.0 is now available for download at: https://cmake.org/download/ Documentation is available at: https://cmake.org/cmake/help/v3.6 Release notes appear below and are also published at https://cmake.org/cmake/help/v3.6/release/3.6.html Some of the more significant features of CMake 3.6 are: * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. * A "_CLANG_TIDY" target property and supporting "CMAKE__CLANG_TIDY" variable were introduced to tell the Makefile Generators and the "Ninja" generator to run "clang-tidy" along with the compiler for "C" and "CXX" languages. * The "ExternalProject" module leared the "GIT_SHALLOW 1" option to perform a shallow clone of a Git repository. * The "ExternalProject" module learned to initialize Git submodules recursively and also to initialize new submodules on updates. Use the "GIT_SUBMODULES" option to restrict which submodules are initalized and updated. * The "InstallRequiredSystemLibraries" module learned a new "CMAKE_INSTALL_UCRT_LIBRARIES" option to enable app-local deployment of the Windows Universal CRT libraries with Visual Studio 2015. * The "Compile Features" functionality is now aware of features supported by Intel C++ compilers versions 12.1 through 16.0 on UNIX platforms. Deprecated and Removed Features === * The "CMakeForceCompiler" module and its macros are now deprecated. See module documentation for an explanation. * The "Visual Studio 7 .NET 2003" generator is now deprecated and will be removed in a future version of CMake. * The "Visual Studio 7" generator (for VS .NET 2002) has been removed. It had been deprecated since CMake 3.3. * The "Visual Studio 6" generator has been removed. It had been deprecated since CMake 3.3. CMake 3.6 Release Notes *** Changes made since CMake 3.5 include the following. New Features Generators -- * The "Ninja" generator learned to produce phony targets of the form "sub/dir/all" to drive the build of a subdirectory. This is equivalent to "cd sub/dir; make all" with Makefile Generators. * The "Ninja" generator now includes system header files in build dependencies to ensure correct re-builds when system packages are updated. * The "Visual Studio 14 2015" generator learned to support the Clang/C2 toolsets, e.g. with the "-T v140_clang_3_7" option. This feature is experimental. Commands * The "add_custom_command()" and "add_custom_target()" commands learned how to use the "CROSSCOMPILING_EMULATOR" executable target property. * The "install()" command learned a new "EXCLUDE_FROM_ALL" option to leave installation rules out of the default installation. * The "list()" command gained a "FILTER" sub-command to filter list elements by regular expression. * The "string(TIMESTAMP)" and "file(TIMESTAMP)" commands gained support for the "%s" placeholder. This is the number of seconds since the UNIX Epoch. Variables - * A "CMAKE_DEPENDS_IN_PROJECT_ONLY" variable was introduced to tell Makefile Generators to limit dependency scanning only to files in the project source and build trees. * A new "CMAKE_HOST_SOLARIS" variable was introduced to indicate when CMake is running on an Oracle Solaris host. * A "CMAKE__STANDARD_INCLUDE_DIRECTORIES" variable was added for use by toolchain files to specify system include directories to be appended to all compiler command lines. * The "CMAKE__STANDARD_LIBRARIES" variable is now documented. It is intended for use by toolchain files to specify system libraries to be added to all linker command lines. * A "CMAKE_NINJA_OUTPUT_PATH_PREFIX" variable was introduced to tell the "Ninja" generator to configure the generated "build.ninja" file for use as a "subninja". * A "CMAKE_TRY_COMPILE_PLATFORM_VARIABLES" variable was added for use by toolchain files to specify platform-specific variables that must be propagated by the "try_compile()" command into test projects. * A "CMAKE_TRY_COMPILE_TARGET_TYPE" variable was added to optionally tell the "try_compile()" command to build a static library instead of an executable. This is useful for cross-compiling toolchains that cannot link binaries without custom flags or scripts. Properties -- * A "DEPLOYMENT_REMOTE_DIRECTORY" target property was introduced to tell the "Visual Studio 9 2008" and "Visual Studio 8 2005" generators to generate th
Re: The situation of KWallet, and what to do about it?
On 07 Jul, Thomas Pfeiffer wrote : > - It works only with KDE Frameworks-based applications FWIW, we implemented Kwallet inside VLC by using the DBus interface, see: https://git.videolan.org/?p=vlc.git;a=commit;h=26f1032193c0b338494f32895e64162ed4ead8ab without being a KDE Frameworks-based applications With my kindest regards, -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device
Re: The situation of KWallet, and what to do about it?
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 signature.asc Description: This is a digitally signed message part.
Re: The situation of KWallet, and what to do about it?
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 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
