Wiki - https://fedoraproject.org/wiki/Changes/oo7_Secrets_Service_Provider Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-oo7-secrets-servi...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Switch the default Secrets Service provider for Fedora desktops from KWallet and GNOME Keyring to oo7.
== Owner == * Name: [[User:ngompa| Neal Gompa]], [[User:decathorpe| Fabio Valentini]], [[User:salimma| Michel Lind]] * Email: ngompa13@gmail.com, decathorpe@gmail.com, michel@michel-slm.name
== Detailed Description == A new universal secrets storage system has been developed in the form of [https://github.com/linux-credentials/oo7 oo7] that replaces KWallet's backend and GNOME Keyring. Package up <code>oo7-daemon</code> and associated support code and change the Fedora default secrets storage backend to it across all desktops.
== Feedback ==
== Benefit to Fedora == The idea with this new secrets storage system is to support a new model for credentials where scoped authorization is possible for applications and services. Additionally, it opens the door for mediating access to FIDO2-based authentication mechanisms. This lends itself well to enabling limited trust to secrets for sandboxed applications, among other things. KDE Plasma, COSMIC, and GNOME (among others) are all converging on this and so enabling this allows Fedora to remain at the forefront of supporting desktop technologies.
== Scope == * Proposal owners: ** Package <code>oo7-daemon</code>, PAM module, and other support code ** Add oo7 PAM module to relevant PAM configs where gnome-keyring and kwallet PAM modules are listed ** Adjust comps to replace gnome-keyring with oo7-daemon ** Adjust dependencies in desktops to use oo7 instead of gnome-keyring
* Other developers: N/A (not needed for this Change)
* Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues/13405 #13405]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact == The oo7 service will automatically migrate existing data from GNOME Keyring and KWallet, so no user interaction is required to handle the transition.
== How To Test == Once oo7-daemon and related code are packaged and updated configuration lands in Rawhide, users can test this simply by upgrading and using things that leverage the secrets service like normal.
== User Experience == This is expected to be fairly transparent to the user.
== Dependencies == This will involve updating the PAM configuration files for the desktops and login managers used across Fedora deliverables.
== Contingency Plan == * Contingency mechanism: Revert swap to oo7 and defer to the next release * Contingency deadline: Beta freeze * Blocks release? Yes
== Documentation == More information about oo7 is present in [https://docs.rs/oo7/ the upstream project documentation].
== Release Notes == Fedora Linux now uses the oo7 as the default secrets service provider, replacing older solutions like GNOME Keyring. This brings enhanced security to secrets management, particularly for sandboxed applications, and enables FIDO2 authentication secrets.
Will seahorse use this backend also, or will it still use GNOME keyring daemon?
Will the secret-tool CLI and libsecret use this backend by default?
Will this work seamlessly with the existing git-credential-helper?
Will existing askpass utilities that currently work in gnome for gpg and ssh still work with this?
GNOME supports multiple keyrings. Will this support multiple keyrings? On upgrade, how will secrets be migrated if multiple keyrings are used? Will migration be easy if the GNOME keyrings are not unlocked by PAM (because they have a different passphrase than the account, for example).
How, if at all, will saved passwords in GNOME Online Accounts (goa) be affected?
Will any fedora-packager tools be affected, such as fpkinit?
Sorry for all the questions, but this seems like a big change for me. I've been a g-k-d user for a very long time!
On Tue, Jun 30, 2026, 13:26 Aoife Moloney via devel-announce < devel-announce@lists.fedoraproject.org> wrote:
Wiki - https://fedoraproject.org/wiki/Changes/oo7_Secrets_Service_Provider Discussion thread -
https://discussion.fedoraproject.org/t/f45-change-proposal-oo7-secrets-servi...
This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Switch the default Secrets Service provider for Fedora desktops from KWallet and GNOME Keyring to oo7.
== Owner ==
- Name: [[User:ngompa| Neal Gompa]], [[User:decathorpe| Fabio
Valentini]], [[User:salimma| Michel Lind]]
- Email: ngompa13@gmail.com, decathorpe@gmail.com, michel@michel-slm.name
== Detailed Description == A new universal secrets storage system has been developed in the form of [https://github.com/linux-credentials/oo7 oo7] that replaces KWallet's backend and GNOME Keyring. Package up <code>oo7-daemon</code> and associated support code and change the Fedora default secrets storage backend to it across all desktops.
== Feedback ==
== Benefit to Fedora == The idea with this new secrets storage system is to support a new model for credentials where scoped authorization is possible for applications and services. Additionally, it opens the door for mediating access to FIDO2-based authentication mechanisms. This lends itself well to enabling limited trust to secrets for sandboxed applications, among other things. KDE Plasma, COSMIC, and GNOME (among others) are all converging on this and so enabling this allows Fedora to remain at the forefront of supporting desktop technologies.
== Scope ==
- Proposal owners:
** Package <code>oo7-daemon</code>, PAM module, and other support code ** Add oo7 PAM module to relevant PAM configs where gnome-keyring and kwallet PAM modules are listed ** Adjust comps to replace gnome-keyring with oo7-daemon ** Adjust dependencies in desktops to use oo7 instead of gnome-keyring
Other developers: N/A (not needed for this Change)
Release engineering:
[https://forge.fedoraproject.org/releng/tickets/issues/13405 #13405]
Policies and guidelines: N/A (not needed for this Change)
Trademark approval: N/A (not needed for this Change)
Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact == The oo7 service will automatically migrate existing data from GNOME Keyring and KWallet, so no user interaction is required to handle the transition.
== How To Test == Once oo7-daemon and related code are packaged and updated configuration lands in Rawhide, users can test this simply by upgrading and using things that leverage the secrets service like normal.
== User Experience == This is expected to be fairly transparent to the user.
== Dependencies == This will involve updating the PAM configuration files for the desktops and login managers used across Fedora deliverables.
== Contingency Plan ==
- Contingency mechanism: Revert swap to oo7 and defer to the next release
- Contingency deadline: Beta freeze
- Blocks release? Yes
== Documentation == More information about oo7 is present in [https://docs.rs/oo7/ the upstream project documentation].
== Release Notes == Fedora Linux now uses the oo7 as the default secrets service provider, replacing older solutions like GNOME Keyring. This brings enhanced security to secrets management, particularly for sandboxed applications, and enables FIDO2 authentication secrets.
-- Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
-- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro... Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Hi, oo7 author here
Will seahorse use this backend also, or will it still use GNOME keyring
daemon?
Seahorse uses the secret service API underhood, so it should work with both oo7-daemon and gnome-keyring-daemon. No need for the later anymore.
Will the secret-tool CLI and libsecret use this backend by default?
Yes. But we have a better replacement of secret-tool called oo7-cli. For example the former doesn't prompt you to unlock a keyring when using the CLI, oo7-cli does. It also supports reading local keyrings (your backups, if you pass in the secret to decrypt them).
Note I do have a goal to replace the libsecret API with something else but no work is being done there.
Will this work seamlessly with the existing git-credential-helper?
No clue what is that, but it likely uses secret service dbus api, so it would work. Test it? :)
Will existing askpass utilities that currently work in gnome for gpg and
ssh still work with this?
Those are not related.
GNOME supports multiple keyrings. Will this support multiple keyrings? On
upgrade, how will secrets be migrated if multiple keyrings are used? Will migration be easy if the GNOME keyrings are not unlocked by PAM (because they have a different passphrase than the account, for example).
The new daemon supports multiple keyrings, auto unlock through PAM and if the password is not provided through PAM, then the user is prompted to unlock them the moment you interact with them.
How, if at all, will saved passwords in GNOME Online Accounts (goa) be affected?
same as above, that uses secret service dbus API, it just works.
Will any fedora-packager tools be affected, such as fpkinit?
No clue what that uses.
On 6/30/26 11:47 PM, Bilal Elmoussaoui wrote:
Hi, oo7 author here
Your quoting is a little broken.
GNOME supports multiple keyrings. Will this support multiple keyrings? On
upgrade, how will secrets be migrated if multiple keyrings are used? Will migration be easy if the GNOME keyrings are not unlocked by PAM (because they have a different passphrase than the account, for example).
The new daemon supports multiple keyrings, auto unlock through PAM and if the password is not provided through PAM, then the user is prompted to unlock them the moment you interact with them.
How, if at all, will saved passwords in GNOME Online Accounts (goa) be affected?
same as above, that uses secret service dbus API, it just works.
This answer is unclear. Are you saying that oo7 will use the existing keyrings automatically?
On 01/07/2026 09:06, Bilal Elmoussaoui wrote:
Yes, it auto migrates keyrings from both gnome-keyring-daemon and kwallet and keep the user data in place (no deletion post migration).
How it will achieve this if the kwallet keyring is encrypted by a separate password?
How it will achieve this if the kwallet keyring is encrypted by a
separate password?
Every keyring it finds, is exposed on the secret service dbus interface (like kwallet/gnome-keyring) do today, the moment the user interacts with one, if locked, would be prompted to type the password to unlock it, the moment it is unlocked, it gets migrated.
On 01/07/2026 09:29, Bilal Elmoussaoui wrote:
Every keyring it finds, is exposed on the secret service dbus interface (like kwallet/gnome-keyring) do today, the moment the user interacts with one, if locked, would be prompted to type the password to unlock it, the moment it is unlocked, it gets migrated.
How it will interact with kwallet/gnome-keyring if the other keyrings are replaced at the RPM level as proposed? Or will oo7 have its own importers that can read encrypted files?
P.S. Please configure your email client, as it breaks quotes.
It doesn't interact with them, it read the files itself, it has parsers for boths. Removing kwallet/gnome-keyring doesn't remove it keyrings, or at least, it shouldn't.
On 01/07/2026 12:45, Bilal Elmoussaoui wrote:
It doesn't interact with them, it read the files itself, it has parsers for boths.
Great. That's all I wanted to know.
Removing kwallet/gnome-keyring doesn't remove it keyrings, or at least, it shouldn't.
Yes. RPM packages can't touch users' /home directories.
On 30/06/2026 19:19, Aoife Moloney via devel-announce wrote:
The idea with this new secrets storage system is to support a new model for credentials where scoped authorization is possible for applications and services. Additionally, it opens the door for mediating access to FIDO2-based authentication mechanisms.
Why does this require a new daemon, and why can't this be implemented in existing, well-known keyrings?
This lends itself well to enabling limited trust to secrets for sandboxed applications, among other things.
AFAIK, both KWallet and GNOME Keyring already allow you to restrict access based on the application name.
Wallet Manager -> Applications tab -> Authorized applications.
AFAIK, both KWallet and GNOME Keyring already allow you to restrict
access based on the application name.
That is not true for neither, because the spec has nothing about that.
Why does this require a new daemon, and why can't this be implemented in
existing, well-known keyrings?
Because both kwallet and gnome-keyring-daemon are not maintained anymore. So this an opportunity to merge both (and likely other major desktops) to use the same keyring and focus on a single impl of the specification.
On 01/07/2026 09:28, Bilal Elmoussaoui wrote:
That is not true for neither, because the spec has nothing about that.
This is true because I have seen a lot of requests for access to KWallet keychain.
You can even set the list of allowed applications in KMenu -> Wallet Manager -> Applications.
Because both kwallet and gnome-keyring-daemon are not maintained anymore.
KWallet: last commit June 24, 2026. GNOME Keyring: last commit May 4, 2026.
So this an opportunity to merge both (and likely other major desktops) to use the same keyring and focus on a single impl of the specification.
What do KDE and GNOME developers think about this?
On 01/07/2026 12:52, Bilal Elmoussaoui wrote:
Both agree on switching to this
Do you have links to their reactions? Perhaps blog posts, ML discussions, or Bugzilla posts?
latest commit being recent doesn't mean it is maintained
https://github.com/KDE/kwallet/commits/master - I see a lot of commits, so the project is maintained.
https://github.com/GNOME/gnome-keyring/commits/main - mostly localization updates and bug fixes.
GNOME upstream already replaced gnome-keyring with oo7 last month, see: https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/4788
On Wed, Jul 1, 2026, at 2:23 AM, Vitaly Zaitsev via devel wrote:
AFAIK, both KWallet and GNOME Keyring already allow you to restrict access based on the application name.
Wallet Manager -> Applications tab -> Authorized applications.
(Keep in mind such functionality can only possibly work for sandboxed applications. There's of course no way to stop an unsandboxed application from reading whatever it wants.)
On 01/07/2026 17:08, Michael Catanzaro via devel wrote:
(Keep in mind such functionality can only possibly work for sandboxed applications. There's of course no way to stop an unsandboxed application from reading whatever it wants.)
Sure. All current wallets and password managers have the same issue. The only way to prevent unsandboxed applications from accessing encrypted password manager databases is to store them on a separate hardware token or TPM chip, which is not possible today because the number of slots on such devices is very limited.
Storing the primary encryption key on a hardware token is better, but the unsandboxed application will still be able to read the wallet's memory, extract the KEK from there, and then decrypt the database.
-
Aoife Moloney via devel-announce -
Bilal Elmoussaoui -
Christopher -
Michael Catanzaro -
Samuel Sieb -
Vitaly Zaitsev