KWallet needs a serious face-lift ; enter KSecret Service

Users are often confused by the current KWallet system behavior. When their computers start, they enter the KDE session password but just after logging-in, they are prompted yet another password, for something named KWallet. Sometimes, they even see several password prompts from KWallet, depending on their precise desktop configuration.

Some users find that annoying and they file bug reports or, even worse, simply uncheck the “Enable the KDE wallet subsystem” in an attempt to deactivate it as a whole and switch to using some other external tools. Well, these tools are OK, but the KDE experience is affected, as the applications are no longer able to correctly store and retrieve their secrets. And that raises the barrier to entry for some of our potential users, adding negative points against KDE.

The remaining users have now several devices and would like to have their passwords synchronized all over these devices. They won’t find this kind of function and they’ll start using some other external tools, providing cross-device synchronization. That’s another bad point for the KDE experience.

Finally, more advanced users would like to know where their wallet data is stored and they would like to be able to put their wallets in some places of their choice, perhaps in an owncloud synchronized directory.

Enter KSecret Service!

The KDE Wallet system has some design flaws (I’ll write more on that in the future, but right now my post risk to get too long) affecting the security and should be replaced ASAP. Back in 2008 and until or 2011 an initiative was taken by the former KDE Wallet maintainer Michael Leupold and Stef Walter from GNOME to create a interface aiming to replace it. It’s called “Secret Service” and the draft may be found here:

This interface is already implemented by GNOME keyring and AFAICT KDE should also implement this interface if it wanted to enhance users experience.

All these points will be addressed by a new system, aiming to replace KWallet. It’s name is already known – KSecret Service.

I’m in the process of (re)defining it’s architecture and I’ll post it, for feedback, on the KDE developer mailing list as soon as I’ll get something stable enough. I cannot tell more right now – the post is already long enough – but it’s an ambitious plan! And I’m sure you’ll like it!


40 thoughts on “KWallet needs a serious face-lift ; enter KSecret Service”

  1. You are right, I already like it. KWallet was great when it was introduces, but as you pointed out, it is no longer the freshest. Thanks for working on this.

  2. Is KWallet comparable to KeePassX or LastPass?

    What do you think about allowing users to log in with a 4-6 character pin instead of their user password? That way I can use a gpg backend wallet and also use the same password for my user which would be a long password and entering it once as a single sign-on. A 4-6 character pin is easy to use when unlocking system, etc.

    1. Well, the paper I’m working on is not yet ready, but I can already tell you that the secrets unlock will use your password, via a dedicated pam module in conjunction with the kernel keyring.

  3. Yes!! Kwallet confusion is the single biggest disincentive to using KDE, I’m sure. The tools are written from the perspective of a developer and the setup — with its talk of GPG and Blowfish — assumes the user is knowledgable about encryption. E.g., it tells me GPG is better, but then abandons me. What if I have no idea what GPG is?

    Good wishes on accompishing this sorely needed improvement. I just hope the current bugs that see the “new” KDE display migration prompts for “old” wallets that are not there, plus the one that sees KMail prompting for an IMAP password that is clearly in the wallet and that it can access… are fixed.

    1. Thanks for your support! FYI, the KDE migration was fixed and you’ll get it soon, with the just released KF5 5.10.0. The KMail problem is not really KWallet related. However, the new KSecret service will hopefully be more usable for the KDE applications.

      1. Here’s an example of how Kwallet now can be confusing, at least to this user:

        I”ve just done an new install of Debian 8 KDE. I generated a GPG key with Kgpg. I told KWalletManager to tell me when applications tried to access the wallet.

        On the first launch of KMail, of course, Kwallet intervened. I told it to use the GPG key and to always allow KMail and the mail server access to the wallet.

        And, indeed, I am not prompted to allow KMail/IMAP access to the wallet.

        But, every new session when I launch KMail, I am prompted for my GPG passphrase.

        I understand the passphrase is needed to allow access to the wallet. But, as a user, my idea of automated password management is *not* being prompted for passwords. I don’t see the difference between not storing application/server passwords and entering them every time, or storing them in a wallet aka password manager that then prompts for a password every session, or securing the whole thing with GPG and then be asked for its passphrase every session.

        In all cases, I am asked to enter password(s) every session. I’ve gained nothing.

        1. Well, when using the GPG encryption, the GPG key passphrase will always be required. That’s the way GPG works. But I know there are means to integrate it with other systems which could automatically provide the it’s password. I added this to the roadmap of KSecret Service.

  4. That’s true, new users are confused by the behavior of KWallet, the causes that you wrote are important.

    Keep up the good work!

    1. Well, yes, but this time kdelibs splitting was finished, so this project will resume. At that time it was decided to wait kdelibs splitting before continuing it.

  5. Agreed. Also better browser integration would be good. Google uses it, but stores it’s passwords in a different format, which means you can’t view the passwords you’ve stored using Google Chrome, natively in the KWallet interface, and Mozila FF can’t update or access those passwords, so you end up maintaining two copies of passwords and not knowing which one is the latest.

    1. You’re asking for a security flaw :-) If Firefox would be able to read Chrome-managed passwords, that Firefox would be able to also read all the other passwords if we’re not careful. To address this, I think I’ll add a concept of “application group” and let you manage that.

  6. I love KDE but one of the thing i hate the most it is the naming stuff like K-wtf behavior

    1 it is hard to find the application first of all
    2 noto readable the most of case

    Why dont make something like secretservice_k or secretservice-kde

    1. Well, this is well established nowadays and I’ll stick with it. But secretservice-kde is an interesting proposal, I’ll consider it. And this naming scheme let one mix different “Desktop Environments” components without problems.

      1. > it is hard to find the application first of all

        Like they wrote years ago:
        “Seriously. When new to linux, and browsing through the huge garbage pile that is the “available list” of the package manager, finding something with the destinctive “K” is really helpful, because they usually work and at least partly follow the same usability conventions.”

        – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

        It followed the older tradidion of X programs having an x in front of their name, like xterm, xcalc, xbiff, xedit, xlogo, etc.

        – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

        Apple started doing the same with the prefix “i”.

        – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

        Remember: It’s not “Word”, it’s “MS Word”. It’s not “Access”, it’s “MS Access”, etc.

        1. apt-cache search sc | grep ‘kde\|qt’

          problem solved.

          because one goes with MS-stuff it doesn’t mean it’s better

          comfort for users it’s the target ,

          k-stuff it’s not very usefull because you have a LOTS of application that start with k so basically you have to look carefully what you need instead with


          you got a better filter just think to launch an application from terminal , you would say it’ s not the standard way to start a kde-application, right , but how many times you want to debug , start an application with special settings , and basically even if it’s not the standard way to launch an application why you have to increase the efforts ?

          i mean :

          sem@sem-:~$ k
          Display all 181 possibilities? (y or n)

          WTF are you kidding me ?

          and look , i am maybe one of the last konqueror-users out there i mean i totally love kde since kde 3 so it’s because i like kde that i am here to write my opinion

      2. I find it funny to read that “this is well established nowadays”. I am using KDE software since KDE 3.x and back in the day the naming “k…” or “K…” was way more frequent than today, most KDE applications’ names started with a ‘k’. Starting from KDE 4.0 people got bored with the “k…” naming and started to move away from that naming scheme. That’s, for example, why Calligra is not named Kalligra. Program names that still start with ‘k’ are (in most cases) relics of the old KDE 3 days. It is funny to see how the “K…” naming becomes popular again. The pendulum swings back and forth… :-) Anyway, I don’t care how it is named, as long as it works.

  7. >When their computers start, they enter the KDE session
    > password but just after logging-in, they are prompted yet
    > another password, for something named KWallet. Sometimes,
    > they even see several password prompts from KWallet,
    > depending on their precise desktop configuration.

    this! I don’t know why put up with it. When I’ve been working for hours, all I want is a file on an shared external drive (exfat, ntfs), dropbox or network drive. I really don’t want to enter password there. It’s like a captcha for your workflow :(

    p.s: <3 KDE

    1. Exactly. That’s another point the new architecture will address out-of-the box. The synchronization will be allowed natively and you’ll be able to configure the place where the secrets file will be stored. And that may well be an owncloud synchronized directory, or something like that.

    1. By providing the secret service API drafted for the, yes, KSecret Service will be able to receive GNOME applications secrets. And inversely, the GNOME keyring will be able to receive KDE application secrets if you choose to activate it instead of the KSecret Service. You’ll be able to choose between them by the means of the “alternatives” feature.

  8. i used heavily FF with a useful firefox addon “KDE wallet password integration”

    now it’s dev “Guillermo Molina” uses no more FF and seems to abandon the addon development
    he says “I don’t use firefox any more, but I will try to make the plugin work again”

    see here

    i ask to opensuse team to keep on developing this addon

    please do your maximum with guillermo or opensuse team to avoid FF stopping using kwallet


      1. Here it is:
        Unfortunately it stopped working for me recently.

        While I’m very much looking forward to ksecret service (and I agree on all your points) I think browser integration is essential.
        You’re not responsible for that but I think KDE should find maintainers for all frontends (browser, android, …). It would be a shame to have a nice pw storage which will only be used by one half of the used applications.

    1. passwordstore is an interesting solution, but it’s not part of KDE. Providing a backend for it might be interesting for the power users, able to handle this kind of infrastructure. You’ll find some of it’s concepts int the new KSecret Service. I’ll add a passwordstore backend to the roadmap and everyone wiling to help will be welcome once the initial release of KSecret Service will be done.

  9. Yes, thank you.

    I’ve been trying to synchronize kde wallet (~/.share/apps/kwallet/) across a couple of computers with unison, and that doesn’t seem to work as it is only possible to synchronize these files when the wallet is closed, but the first things happens whenever I start my computer — the wallet gets open either because of encrypted wifi or firefox ( synchronizing passwords with firefox is it’s own issue btw).

    A new version of wallet is really needed, please post the updates when you get the project workspace going — I can do some testing.

Leave a Reply

Your email address will not be published. Required fields are marked *