Replace kwallet with oo7-daemon

bilelmoussaoui commented

2026-03-25 12:04:04 +00:00

I would like to suggest replacing kwallet with oo7-daemon https://github.com/linux-credentials/oo7/tree/main/server as a Rust re-implementation of the secret service specification.

Currently fedora already ships oo7 (the client library that the daemon is built upon) along with oo7-cli, a secret-tool replacement so most of the dependencies are there already.

oo7-daemon, offers a full drop-in replacement of gnome-keyring-daemon/kwallet with PAM support as well. It has good test coverage and works out of the box on both GNOME and KDE Plasma making it possible to eventually drop both gnome-keyring-daemon and kwallet.

KDE upstream is interested in using that as a replacement of kwallet as they have implemented the necessary prompting interfaces at https://invent.kde.org/mart/ksecretprompter.

Both the daemon and client library offers two cryptographic backends; one based on Rust native libraries and one based on openssl so it not be a problem to use the opeenssl based one if desired.

Please let me know if further information is needed.

This must be implemented in coordination with workstation/tickets#506

I would like to suggest replacing kwallet with oo7-daemon https://github.com/linux-credentials/oo7/tree/main/server as a Rust re-implementation of the secret service specification. Currently fedora already ships oo7 (the client library that the daemon is built upon) along with oo7-cli, a secret-tool replacement so most of the dependencies are there already. oo7-daemon, offers a full drop-in replacement of gnome-keyring-daemon/kwallet with PAM support as well. It has good test coverage and works out of the box on both GNOME and KDE Plasma making it possible to eventually drop both gnome-keyring-daemon and kwallet. KDE upstream is interested in using that as a replacement of kwallet as they have implemented the necessary prompting interfaces at https://invent.kde.org/mart/ksecretprompter. Both the daemon and client library offers two cryptographic backends; one based on Rust native libraries and one based on openssl so it not be a problem to use the opeenssl based one if desired. Please let me know if further information is needed. This must be implemented in coordination with https://forge.fedoraproject.org/workstation/tickets/issues/506

ngompa added this to the Fedora Linux 45 milestone

2026-03-25 12:12:08 +00:00

ngompa added the

labels

2026-03-25 12:12:33 +00:00

nicolasfella commented

2026-03-25 12:41:52 +00:00

Would you suggest to replace it for existing installations or only new ones?

ngompa commented

2026-03-25 12:45:10 +00:00

Owner

I think it might wind up being done on upgrades too, because of the PAM changes.

bilelmoussaoui commented

2026-03-25 12:45:37 +00:00

Author

We don't have a way to migrate from kwallet keyrings to oo7-daemon ones. So if it is possible to only replace it for new installations, I would start with that.

bilelmoussaoui commented

2026-03-25 12:46:24 +00:00

Author

Although, if that is the only blocker we have, I might spend some time in adding support for that as well.

ngompa commented

2026-03-25 12:47:27 +00:00

Owner

@bilelmoussaoui wrote in #700 (comment):

Although, if that is the only blocker we have, I might spend some time in adding support for that as well.

Realistically, I think that is probably the only major blocking issue, as the mechanics of the rest of it is straightforward.

@bilelmoussaoui wrote in https://forge.fedoraproject.org/kde/tracker/issues/700#issuecomment-592210: > Although, if that is the only blocker we have, I might spend some time in adding support for that as well. Realistically, I think that is probably the only major blocking issue, as the mechanics of the rest of it is straightforward.

bilelmoussaoui commented

2026-03-25 13:28:12 +00:00

Author

I am forwarding this message from David Edmundson

To perform a migration someone needs to set:

kwalletrc:

[Wallet]
apiEnabled=false  
(disables our backend, forces kwallet calls to be redirected to secret service)

[Migration]
MigrateTo3rdParty=true 
(put existing data on the active secrets provider)
WalletsMigratedToSecretService= 
(list of things that have been copied should be blank to copy again)

and we have a few things we need to solve for things to work smoothly.

make QtKeychain look up apiEnabled and use libsecret (or have startplasma do it and set the env explicitly) Otherwise on Plasma things take a stupid roundtrip, though it should work in theory.
Modify Plasma Login Manager pam files to include oo7
Users KCM password changing needs to go via pam directly and not AccountsService
Portals : ksecretd apparently provides a portal impl, we need that to be overriden to be oo7

I am forwarding this message from David Edmundson > To perform a migration someone needs to set: kwalletrc: ``` [Wallet] apiEnabled=false (disables our backend, forces kwallet calls to be redirected to secret service) [Migration] MigrateTo3rdParty=true (put existing data on the active secrets provider) WalletsMigratedToSecretService= (list of things that have been copied should be blank to copy again) ``` and we have a few things we need to solve for things to work smoothly. * make QtKeychain look up apiEnabled and use libsecret (or have startplasma do it and set the env explicitly) Otherwise on Plasma things take a stupid roundtrip, though it should work in theory. * Modify Plasma Login Manager pam files to include oo7 * Users KCM password changing needs to go via pam directly and not AccountsService * Portals : ksecretd apparently provides a portal impl, we need that to be overriden to be oo7

👍 1

nicolasfella commented

2026-03-25 14:42:21 +00:00

kwalletd has code to migrate stuff to the o.f.secrets provider, but we need to make sure something triggers that since kwalletd is launched on demand

👍 1

nicolasfella commented

2026-03-25 14:43:13 +00:00

If oo7 takes over the secrets portal we need to make sure that existing portal secrets from kwallet are migrated correctly.

nicolasfella commented

2026-03-25 14:44:39 +00:00

We also need to make sure that the KWallet UI in systemsettings (kwalletmanager) behaves sensibly. The configuration UI for it has lots of options that don't apply to oo7 that shouldn't be shown then

siosm commented

2026-03-25 15:05:25 +00:00

Member

We don't have a way to migrate from kwallet keyrings to oo7-daemon ones. So if it is possible to only replace it for new installations, I would start with that.

We don't have that kind of option for Silverblue and Kinoite so this means that we will have to ship both for a while and let user migrate. An automatic migration path would be great.

> We don't have a way to migrate from kwallet keyrings to oo7-daemon ones. So if it is possible to only replace it for new installations, I would start with that. We don't have that kind of option for Silverblue and Kinoite so this means that we will have to ship both for a while and let user migrate. An automatic migration path would be great.

siosm referenced this issue from workstation/tickets

2026-03-25 15:07:58 +00:00

Replace gnome-keyring-daemon with oo7-daemon #506

nicolasfella commented

2026-03-25 17:34:54 +00:00

Related KDE Linux ticket: https://invent.kde.org/kde-linux/kde-linux/-/issues/566

nicolasfella commented

2026-03-25 17:35:51 +00:00

KDE upstream is interested in using that as a replacement of kwallet as they have implemented the necessary prompting interfaces at https://invent.kde.org/mart/ksecretprompter.

This now lives at https://invent.kde.org/plasma/plasma-workspace/-/tree/master/ksecretprompter

> KDE upstream is interested in using that as a replacement of kwallet as they have implemented the necessary prompting interfaces at https://invent.kde.org/mart/ksecretprompter. This now lives at https://invent.kde.org/plasma/plasma-workspace/-/tree/master/ksecretprompter

bilelmoussaoui commented

2026-03-26 08:15:55 +00:00

Author

@siosm wrote in #700 (comment):

We don't have a way to migrate from kwallet keyrings to oo7-daemon ones. So if it is possible to only replace it for new installations, I would start with that.

We don't have that kind of option for Silverblue and Kinoite so this means that we will have to ship both for a while and let user migrate. An automatic migration path would be great.

I noticed that kwallet supports GPG as well, do we know how widely that is used? That would make automatic migration difficult. In any case, I spent some time last evening writing a parser of the kwallet file format so I can do automatic migration for it similar to gnome-keyring v0 format: https://github.com/linux-credentials/oo7/pull/439

If anyone using KDE and wants to try it out, kwallet-cli should give you a list of all your tokens.

@siosm wrote in https://forge.fedoraproject.org/kde/tracker/issues/700#issuecomment-593192: > > We don't have a way to migrate from kwallet keyrings to oo7-daemon ones. So if it is possible to only replace it for new installations, I would start with that. > > We don't have that kind of option for Silverblue and Kinoite so this means that we will have to ship both for a while and let user migrate. An automatic migration path would be great. I noticed that kwallet supports GPG as well, do we know how widely that is used? That would make automatic migration difficult. In any case, I spent some time last evening writing a parser of the kwallet file format so I can do automatic migration for it similar to gnome-keyring v0 format: https://github.com/linux-credentials/oo7/pull/439 If anyone using KDE and wants to try it out, kwallet-cli should give you a list of all your tokens.

ngompa commented

2026-04-09 10:35:30 +00:00

Owner

I noticed that kwallet supports GPG as well, do we know how widely that is used? That would make automatic migration difficult.

I have no idea how commonly used the GPG encrypted wallet format is used. At least in Fedora, we default to the Blowfish one and try to ensure it's connected to user login credentials.

> I noticed that kwallet supports GPG as well, do we know how widely that is used? That would make automatic migration difficult. I have no idea how commonly used the GPG encrypted wallet format is used. At least in Fedora, we default to the Blowfish one and try to ensure it's connected to user login credentials.

ngompa self-assigned this

2026-06-02 14:18:29 +00:00

fossdd referenced this issue from cosmic/SIG

2026-06-22 07:32:50 +00:00

Replace gnome-keyring with oo7-daemon #13

ngompa commented

2026-06-30 10:26:31 +00:00

Owner

Change filed: https://fedoraproject.org/wiki/Changes/oo7_Secrets_Service_Provider

❤️ 1 🎉 1

siosm commented

2026-09-15 20:59:25 +00:00

Member

It looks like this is happening for F45 for GNOME variants with gdm dist-git commit 2bcbc53b and for other desktops with releng/fedora-comps#1326.

But I don't see where this is done for KDE. What am I missing?

It looks like this is happening for F45 for GNOME variants with [gdm dist-git commit 2bcbc53b](https://src.fedoraproject.org/rpms/gdm/c/2bcbc53bf1f3a2a121e01953335b25e63f12e1f3?branch=rawhide) and for other desktops with https://forge.fedoraproject.org/releng/fedora-comps/pulls/1326. But I don't see where this is done for KDE. What am I missing?

ngompa commented

2026-09-15 21:09:48 +00:00

Owner

I have deferred it due to lacking time to deal with integration issues. I'm having some discussions with upstream KDE about it too.

👍 1

ngompa modified the milestone from Fedora Linux 45 to Future Release

2026-09-15 21:30:48 +00:00

siosm commented

2026-09-16 12:12:18 +00:00

Member

OK, so this is deferred only for KDE if I understand correctly? (I'm working on it for the Atomic Desktops in atomic-desktops/config#798).

OK, so this is deferred only for KDE if I understand correctly? (I'm working on it for the Atomic Desktops in https://forge.fedoraproject.org/atomic-desktops/config/pulls/798).

ngompa commented

2026-09-16 12:48:04 +00:00

Owner

Yes, any Fedora variant that uses KDE Plasma Desktop or Plasma Mobile should not require oo7 currently.

👍 1

Rows
Columns

Replace kwallet with oo7-daemon #700