KDE4/KF5 Coinstalability and the KWallet

Plasma 5 is about to become part of the mainstream Linux distributions, and we are getting more and more feedback about this new platform. This blog post is a reaction to this increasing feedback from our users.

Plasma5 introduces the KDE Frameworks 5 platform (or KF5) which uses Qt5 as it’s foundation. This new platform aims to replace the legacy KDE4 platform, which was mainly the old monolithic kdelibs. More and more applications got ported to this new platform. Just stay tuned with the next release announcement, which is imminent. However, some applications, and among them some important ones, are not yet ported to the KF5 platform. And this brings on, or more appropriately reminds, the coinstalability matter.

Back in time, KWallet was split from kdelibs and the KF5/KWallet Framework has been created. This is the API part. For non-programmers, this part is the one used by the applications to store the passwords or other secrets into the KDE Wallet System. The applications that were ported to KF5 are now using the new KF5/KWallet framework.

The KDE Wallet System has two other components. The KWalletManager users know very well and the background service, kwalletd, that actually do the work and securely store the secrets on disk. In KDE4, these two components lived in two other places: kdeutils/kwalletmanager and kde-runtime/kwalletd. This separation has always been somewhat confusing and the decision was made to bring the runtime component inside KF5/KWallet framework. This runtime component has also been ported to Qt5. And the coinstalability constraint led us to rename it to kwalletd5. So the applications that were ported to KF5 are now using kwalletd5 behind the scenes, as the KF5/KWallet framework connects to this new runtime.

The KWalletManager was not accepted for inclusion in the KF5/KWallet framework and it still lives under kdeutils. It has been ported to KF5/Qt5 under the branch named “frameworks”. Same coinstalability constraints were applied, so building KWalletManager from this branch yields kwalletmanager5. This KWalletManager5 would connect, via the KF5/KWallet framework, to the new kwalletd5.

But what happens to the passwords from my KDE4 installation?

There are two possible cases where users are going from KDE4 to Plasma5 and the KF5-based platform. The more usual is the upgrade path. Others may opt for clean install. I’ll address the two cases here, and I’d recommend the upgrade path, as it requires the least user interaction.

When upgrading, your system will get kwalletd5 along with the existing kwalletd. kwalletd5 is designed to detect an existing kwalletd via D-Bus upon starting-up and, if it finds it, it’ll trigger the migration wizard. I already blogged about it: KWallet for Plasma 5 now automatically migrates KDE4 wallets!

If you rather decide to do a clean install, you’ll get kwalletd5. Odds are you’ll also get kwalletd as the Linux distributions would decide to keep it, to let run the still-to-be-ported to KF5 applications. If the home directory was preserved during the installation, then the system should go to the upgrade state upon kwalletd5 start-up, as the kwalletd5 would detect the kwalletd, which in turn would find your old wallets. So you should get the migration wizard triggered, and your passwords should land into kwalletd5.

If you opt for a clean home directory along the new install, then you’ll want to export your wallets prior to reinstalling the system. Then re-import your wallets both in KWalletManager and KWalletManager5! As such, applications still using the KDE4 infrastructure will find your passwords.

As long as you’ll continue using KDE4 applications, you’ll have to maintain the two copies of your wallets. But I expect that this would not last as the applications are being quickly ported to KF5. I agree that’s not very convenient, but I’ll add that I already managed to uninstall the old kwalletd, so you should also get there anytime soon.

What about the Chrome or Firefox integration?

Firefox is now compatible with KF5/KWallet, read the announcement on the blog of Andreas Scarpino here

Chromium is not yet compatible AFAIK. Feel free to file a bug report on their bug-tracking system here if you want it brought to you.

In conclusion

I hope that this rather long blog post would bring some light on the new KF5-base KWallet infrastructure. I’d like to thank users that file bugs and by doing this let us improve our software.


4 thoughts on “KDE4/KF5 Coinstalability and the KWallet”

  1. Since application talk to kwallet via dbus, could kwalletd5 also use the kwalletd dbus name so kde4 application can also talk to kwalletd5 without modification?

    1. While this might be possible, it’ll prevent kwalletd5 to be run on systems where kwalletd is present. And if it starts first, it’ll prevent kwalletd to claim it’s D-Bus names. This might be addressed by dropping the KDE4 kwalletd, but KDE4 is far from being discontinued right now.

  2. Keep up good work!

    And what about fd.o SecretService API? Is KWallet going to support it and is it going to become a unified standard?

Leave a Reply

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