Tag Archives: kwallet

KWallet, SecretService, oo7: the story so far

Continuing previous efforts to update the “secure passwords” story of the Plasma desktop, I’ve done some integration work between Plasma and oo7.

Oo7 is a relatively recent SecretService provider written in Rust; it’s very nice, lightweight and cross-desktop. Very interesting for us supporting it as a first class citizen.

We want in the end to replace completely the old KWallet system with something based on SecretService, have all our applications migrated transparently with user data as well, if possible with a cross-desktop backend implementation.

We also want it to be as transparent as possible for the end user, not having any complicated first time setup, or dialogs that ask for a manual unlock when not needed. For the user, the whole system should be just invisible, except when looking up their passwords or when client applications add passwords to it themselves.

As a first thing several months ago we did a transparent translation layer for the KWallet DBus interface, so now the “KWallet” service became just a translation layer between the kwallet api and the secretservice one.

The old kwalletd service instead became “ksecretd” now providing only the SecretService interface, and that’s what we use by default now. however, it can be configured to use a different provider, so it can already be used with gnome-keyring or KeepassXC if the user wishes. In that case the user data will be migrated the first time.

Also I’ve written a new application called KeepSecret. It is centered around SecretService, with a much more modern UI compared to KWalletManager and works also much better on mobile, so we can have also a modern password manager on Plasma Mobile.

KeepSecret running with the oo7 backend, with a native password dialog

The last thing that we did so far is integration with a new SecretService provider on the block: oo7.

If oo7 is Just another SecretSerive provider, Won’t it “just work” in Plasma? Not quite, but that’s actually a good thing. Oo7 wants to properly integrate with the environment it runs in, so we need to build that integration.

When you use KWallet, KeepassXC, or gnome-keyring directly, they create their own password dialogs using their own toolkits and styles, therefore potentially looking a bit alien when run in a different environment than the one it it was designed for.

This is not ideal for evaluating options for a possible future replacement of KWallet (which piece by piece we are working towards), as we want the UI part completely integrated with the Plasma desktop.

Instead, oo7 is built on the assumption that the environment it runs on will provide its own dialogs, a bit like the portal system for services like screen sharing and file picking.
This requires active integration both on the Plasma part and the oo7 part, but on the other hand it will look native on Plasma, Gnome, and any other platform that implements the integration hooks. And that’s with the added benefit of sharing the password storage if someone every now and then goes desktop environment hopping.

On the Plasma side we decided to employ a very small daemon which is launched only on demand with dbus activation. It will create the needed system dialogs, pass the user input back to oo7 and then quit when not needed anymore, so it won’t constantly use up system resources.

This is already available in Plasma 6.6: the code for it is here. It’s designed first for oo7, but it can be used by any daemon which wishes to provide native password dialogs, so we might start to use it also from other components in the future, either other SecretService providers or completely different things which have similar needs like Polkit.

On the oo7 part, Harald implemented the integration with its dbus interface, so with oo7 from main branch (or its next release) it can be used in place of KWallet (with all old applications still using the KWallet API using its backend as well), with all data migrated to it, and it will show native UI for its password dialogs… all the pieces of the puzzle slowly falling together 🙂

Needless to say this is still at an experimental stage, but it’s an important milestone in getting more independent from the aging KWallet infrastructure.

KWallet to SecretService, a client application: name wanted

As i wrote in the previous post, now the KWallet service has been splitted in a compatibility layer that exposes the old KWallet api, but actually consumes the Secret Service API, provided by default by the old KWallet daemon converted in a secretservice-only provider.

Another pain point is the application used to look inside the wallets, KWalletmanager, which only speaks the KWallet api and looks a bit dated nowdays:

I am working on a new application which goal is strictly to be a client for Secret Service. It can access passwords of any Secret Service provider (being KWallet, Gnome-keyring, KeepassXC, oo7 or whatever else) and should hopefully look a bit more modern and simple, while still being powerful:

Both as a desktop application or a mobile one:

For items imported from KWallet supports editing the values of type “Map” as well:

As well as visualizing “binary” entries (here super censored for obvious reasons 😉

The application can be tested at https://invent.kde.org/mart/kwallets

But has a fundamental problem, for which i need help… Right now is just called “KWallets” which can be kinda confusing with old KWallet and KWalletManager, so it probably needs a new name, any opinion is welcome 😄.

Towards a transition from KWallet to Secret Service

Historically passwords and credentials in all of our apps and services (such as kio and our Network Manager plasmoid), are stored and managed by our KWallet subsystem and API. In a similar way, GNOME had gnome-keyring, and other similar systems were available. A major problem was the mutually incompatible interface between them, making impossible to have a single place where all the passwords go.

For this reason, a standard DBus interface called Secret Service has been developed, and systems like KWallet, gnome-keyring and KeepassXC have adopted the interface as well.

In the future, we want to eventually port our applications to use the Secret Service API directly, preferably via the QtKeychain library (some applications already do), which will use Secret Service natively on Linux. And as a bonus the Windows/Android native systems on those platforms will work too.

This will make our applications work much better, be more integrated in other desktops or platforms, and be less dependent on the KWallet framework which has big legacy code parts at this point.

Right now, KWallet has the option to bring up a Secret Service compatible interface, and this is a valuable first step, but there are still some potential problems in the migration path:

Applications using Secret Service will store their secret data in different places when running in different environment, including our own that have been migrated. If you login into a different session ,every app will have forgotten its credentials.
It’s possible to use a different Secret Service provider also in a Plasma session, for instance enabling it in KeepassXC. At that point some apps will save into it, while other ones will keep using KWallet with a different storage backend.
Applications ported from KWallet to SecretService will lose their credentials, unless some clunky porting code is written for each application.

A KWallet compatibility layer

Enter the recent refactor that happened in KWallet: it has now been split into 2 different system services now: one that exposes only the Secret Service API, and one that exposes only the KWallet API.

The service exposing the KWallet API has been written from scratch and is now just a thin wrapper around the Secret Service API, translating the KWallet DBus calls to Secret Service ones. The old KWallet service is now a pure Secret Service provider that just happens to use the old KWallet backend, exposing to Secret Service all the entries that had already been stored in the past.

This decouples our KWallet compatibility layer for existing or old applications (not only KDE applications, also third party ones like Chromium use it) with our actual secret storage and SecretService implementation, allowing a separate development roadmap, and even potential future transition to a different backend in a completely transparent way to the user.

You can see this decoupling in the same spirit as the recent KWin Wayland/X11 split: being able to develop the new technology without risking breaking compatibility of the legacy system.

What it means for users and developers

For the immediate future, not much really changes: users will still have all their secrets accessible, and every app they use that was using KWallet will keep working without forgetting anything.

In the same way, for developers, the whole KWallet C++ API keeps working exactly as it was (even though we’re discouraging its use in new projects). Also, the KWallet-to-Secret-Service API proxy layer will save data inside Secret Service with the same schema used by QtKeychain, keeping the data accessible if the application gets ported from using the KWallet C++ API to QtKeychain.

An experimental feature

Disclaimer: The following description is of an experimental feature behind a hidden configuration key: it will take a bit before it’s deemed ready for prime time.

One advantage of having 2 independent services to handle the KWallet API and the Secret Service one is that now it’s possible to chose different backends as well, such as KeepassXC, gnome-keyring or oo7.

Setting the following in kwalletrc:

[Migration]
MigrateTo3rdParty=true
[KSecretD]
Enabled=false

With this, the old KWallet backend (now a service called ksecretd) won’t be started anymore, and instead any Secret Service provider that is running or has been configured to be DBus-activatable will be used. The first time this happens, a data migration procedure will be executed, writing the data in KWallet into the new service, keeping all the user-saved secrets accessible.

Mart

Tale of a little pixel