nixos/cosmic: migrate from gnome-keyring to oo7 by salva09 · Pull Request #539810 · NixOS/nixpkgs

salva09 · 2026-07-09T03:26:03Z

This pr depends on from #526624
I would appreciate if I could have a double check on the warning message as english is not my main language, thanks!

Things done

salva09 · 2026-07-09T03:39:07Z

`nixpkgs-review` result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 539810 --additional-package nixosTests.cosmic --additional-package nixosTests.cosmic-autologin-noxwayland --additional-package nixosTests.cosmic-noxwayland --additional-package nixosTests.cosmic-autologin
Commit: 0dd4b618848c9a16be19349c7549b14d646e089a

`x86_64-linux`

⏩ 2 packages blacklisted:

nixos-install-tools
tests.nixos-functions.nixos-test

✅ 4 tests built:

nixosTests.cosmic
nixosTests.cosmic-autologin
nixosTests.cosmic-autologin-noxwayland
nixosTests.cosmic-noxwayland

✅ 1 package built:

oo7-pam

nyabinary · 2026-07-09T04:05:44Z

This probably doesn't need stateVersion considering GNOME 51 alpha has oo7 as default.

Pandapip1

Probably worth someone else reviewing in case I missed anything, but nothing obvious that's blocking

Pandapip1 · 2026-07-09T04:22:47Z

+                      name = "oo7";
+                      enable = cfg.oo7.enable;
+                      control = "optional";
+                      modulePath = "${pkgs.oo7-pam}/lib/security/pam_oo7.so";


Probably worth using getLib here?

Maybe could you share an example of where is getLib being used? I haven't seen that before so I don't know how to use it

https://noogle.dev/f/lib/getLib/

Based on the documentation, using that method would evaluate to ${pkgs.oo7-pam}-lib

No, it would evaluate to whichever output contained /lib, assuming the derivation was set up correctly. Basically, if oo7-pam were made into a multi-output derivation, this module would break unless it used getLib.

This is part of #526624, I don't think this should be done. If oo7-pam ever becomes a multi output derivation it can be changed when it happens.

it would evaluate to whichever output contained /lib

This is wrong, it will evaluate to the lib output of a package, if it doesn't contain it, it will fallback to the out output.

it will evaluate to the lib output of a package, if it doesn't contain it, it will fallback to the out output.

"the output that contains /lib" and "the lib output if it exists otherwise the out output" are effectiely the same, but people don't use getLib because of the latter, they use it because of the former

my point is i don't think we should be using it for a package that doesn't have the lib output. I thought this was the standard, but after a quick grep it is not, so it should be fine to do it, though I don't really like it

Pandapip1 · 2026-07-09T04:31:46Z

+    services.gnome.gnome-keyring.enable = lib.mkDefault (lib.versionOlder lib.version "26.11");
+    services.oo7.enable = lib.mkDefault (lib.versionAtLeast lib.version "26.11");


If we're going to predicate this on a version after all, why don't we use stateVersion instead?

I'm also thinking if this version keeping is really necessary? As this change will only be present on 26.11 (as that is where master is at) so the gnome-keyring condition will always be false. And I don't know if the oo7 module alongside this changes would be backported into 26.05

caniko · 2026-07-09T15:03:31Z

I tested the COSMIC/greetd oo7 migration locally on NixOS 26.11 with Electron apps using --password-store=gnome-libsecret against oo7.

The important runtime detail is that COSMIC login goes through the greetd PAM service. With pam_oo7 present but ordered before pam_unix, the module runs but cannot capture the login password:

PAM authentication for user: can
PAM_AUTHTOK is null (password not available)
No auth token available from PAM, skipping stash
...
auto_start argument detected
No stashed password found in session

The Secret Service collection then remains locked after login:

$ busctl --user get-property org.freedesktop.secrets /org/freedesktop/secrets/collection/Login org.freedesktop.Secret.Collection Locked
b true

A working local configuration required pam_oo7 in the auth stack after pam_unix, and pam_unix could not stay sufficient, otherwise successful password auth short-circuits before pam_oo7 runs.

The tested working auth/session shape for greetd was:

auth    required  pam_unix.so ...
auth    optional  pam_oo7.so

session required  pam_unix.so
session optional  pam_oo7.so auto_start
session optional  pam_systemd.so

After switching and logging in again through COSMIC/greetd, oo7 unlocked correctly and VS Code/Goofcord stopped freezing with --password-store=gnome-libsecret.

So I think the security.pam.services.<name>.oo7.enable implementation should ensure pam_oo7 runs after the password provider has populated PAM_AUTHTOK, and should account for pam_unix’s default sufficient control when oo7 password capture is enabled.

salva09 · 2026-07-09T18:38:47Z

Thanks @caniko for your testing! I did some tests to and noticed the same issue where the keyring was not unlocked upon login (although I couldn't replicate the electron apps issue). I'm working on this already

salva09 · 2026-07-10T01:32:07Z

Hi @caniko, could you test again your use case with the latest changes? On my testing the login keyring is successfully migrated on first login, and subsequent logins unlock the keyring automatically

salva09 · 2026-07-10T01:40:20Z

After testing it seems the previous keyring is migrated to oo7 and removed from the system, so if the user rollbacks to gnome-keyring, they will not be able to access their secrets.

Should I add this to the warning message? And also avoid motivating users to go back to gnome-keyring as I do in the current warning message?

thefossguy · 2026-07-10T03:31:46Z

Thanks @caniko for your testing! I did some tests to and noticed the same issue where the keyring was not unlocked upon login (although I couldn't replicate the electron apps issue). I'm working on this already

Would it be possible for you to add a test for this to /nixos/tests/cosmic/?

salva09 · 2026-07-10T04:11:20Z

Would it be possible for you to add a test for this to /nixos/tests/cosmic/?

Sure, I'll try to do it. I haven't done any kind of testing using python, but it doesn't seem that complex as this case can be verified with just logs

thefossguy · 2026-07-10T04:18:58Z

@salva09 I recommend the following flow (that's how I did it):

Build an ISO using nix-build ./nixos --arg configuration ./nixos/modules/installer/cd-dvd/installation-cd-graphical-calamares-cosmic.nix -A config.system.build.isoImage.
Boot into it and experiment with how COSMIC behaves (what logs are in journald, etc) when you run the commands to perform your testing.
Reboot and verify your findings.
Add tests.

Thank you for working on this and all the best! :)

caniko · 2026-07-10T19:13:37Z

Fresh-login validation refined the failure:

The generated PAM stack works: pam_oo7 receives the login secret and oo7 unlocks /org/freedesktop/secrets/collection/Login.
The default alias resolves and the collection is unlocked.
kubectl get --raw=/version still fails when kubelogin writes its Secret Service token cache.
kubelogin's Linux keyring backend checks the hard-coded /org/freedesktop/secrets/collection/login path. oo7 0.6.0 exposes the real collection as Login, so the client falls back to /org/freedesktop/secrets/aliases/default.
oo7 0.6.0 registers that alias on D-Bus but does not resolve aliases inside Unlock, so the keyring write fails.

The generic fix belongs with the oo7 service/package work in #526624. The upstream oo7 fix is server: Resolve aliases in set_locked. PR #539810 should remain focused on COSMIC and greetd integration.

Assisted by: GPT-5.6 Luna

HeitorAugustoLN · 2026-07-10T21:57:46Z

Now, that the module is merged, I guess we should wait until oo7 next release, after looking at the GNOME issue tracker there are some bugs in 0.6.0 that are fixed in the main branch, including the bug @caniko found

salva09 · 2026-07-10T22:10:51Z

In the meantime, I'll see if I'm able to write a cosmic test for this change

nyabinary · 2026-07-10T23:44:09Z

Now, that the module is merged, I guess we should wait until oo7 next release, after looking at the GNOME issue tracker there are some bugs in 0.6.0 that are fixed in the main branch, including the bug @caniko found

Could we just carry that patch? I feel like we should follow upstream COSMIC as much as possible and if they are using oo7 as default so should we.

HeitorAugustoLN · 2026-07-11T00:58:34Z

Could we just carry that patch? I feel like we should follow upstream COSMIC as much as possible and if they are using oo7 as default so should we.

I don't think we need to rush it, the release should not take too long

ninelore

Changing the keyring usually means breaking saved passwords, logins, etc.

Unless there is a absolutely airtight migration I don't think we should touch existing systems, meaning to put it behind stateVersion

salva09 · 2026-07-21T18:29:08Z

Hi @ninelore, upon first login after switching to oo7, the daemon attempts to migrate v0 keyrings (gnome-keyring) to v1. And starting on oo7 0.7.0, after a successful migration, the previous keyring no longer will be deleted and instead will be renamed.

Various fixes and improvements following oo7-daemon's inclusion in GNOME OS. Most notably, successfully migrated keyrings are no longer deleted. Instead, a .stamp file is created to prevent re-migration, leaving the cleanup of old data to the user rather than risking loss of sensitive data.

From oo7 0.7.0.alpha changelog

Are there any considerations we should take into account to decide if this migration mechanism is enough to make the change directly or put it behind a stateVersion check?

HeitorAugustoLN · 2026-07-21T18:41:55Z

Now, in my opinion, by having a backup of old keyring, it should be fine to not gatekeep it. Probably worth of adding a release note for let users know that they can roll back the change if they need to.

ninelore · 2026-07-21T18:44:51Z

Out of curiosity: Hows support for the gcr-ssh-agent or is there an ewuivalent feature?

HeitorAugustoLN · 2026-07-21T19:30:43Z

I haven't tested oo7 yet, I am waiting for 0.7.0, but I guess it should still work fine

salva09 · 2026-07-21T19:44:56Z

I also haven't tested that yet as I don't use it, but I think it should work fine. We just need to explicitly enable it so people making use of it don't lose access to ssh keys without notice

Pandapip1 · 2026-07-21T20:07:12Z

I mean, writing a nixosTest to check this and also catch if this changes would probably satisfy everyone, if anyone has the time to write such a thing.

caniko · 2026-07-21T20:47:10Z

I have it running on my system with this patch; works quite well

ninelore

cant dismiss my request for changes, so im just gonna approve

nixpkgs-ci Bot requested review from a team and Majiir July 9, 2026 03:32

github-project-automation Bot added this to Nix documentation Jul 9, 2026

nyabinary mentioned this pull request Jul 9, 2026

nixos/cosmic: use oo7 for Secret portal #539086

Closed

13 tasks

Pandapip1 approved these changes Jul 9, 2026

View reviewed changes

salva09 force-pushed the cosmic-oo7-migration branch from 0dd4b61 to f985386 Compare July 9, 2026 05:14

nixpkgs-ci Bot added the 12.approvals: 1 This PR was reviewed and approved by one person. label Jul 9, 2026

nixpkgs-ci Bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jul 9, 2026

salva09 force-pushed the cosmic-oo7-migration branch from f985386 to d87ee02 Compare July 9, 2026 18:13

nixpkgs-ci Bot removed the 2.status: merge conflict This PR has merge conflicts with the target branch label Jul 9, 2026

salva09 force-pushed the cosmic-oo7-migration branch from d87ee02 to 518fb57 Compare July 10, 2026 01:24

nixpkgs-ci Bot requested a review from queezle42 July 10, 2026 01:30

DaRacci reviewed Jul 10, 2026

View reviewed changes

Comment thread nixos/modules/services/desktop-managers/cosmic.nix Outdated

Comment thread nixos/modules/services/desktop-managers/cosmic.nix Outdated

nixpkgs-ci Bot added the 2.status: merge conflict This PR has merge conflicts with the target branch label Jul 10, 2026

salva09 force-pushed the cosmic-oo7-migration branch 2 times, most recently from ee64aee to d322c90 Compare July 10, 2026 23:51

nixpkgs-ci Bot removed 8.has: package (new) This PR adds a new package 2.status: merge conflict This PR has merge conflicts with the target branch 8.has: changelog This PR adds or changes release notes labels Jul 10, 2026

ninelore suggested changes Jul 14, 2026

View reviewed changes

ethancedwards8 added the llm-assisted Contributions that include code generation with LLMs label Jul 18, 2026

nixpkgs-ci Bot removed the llm-assisted Contributions that include code generation with LLMs label Jul 18, 2026

ninelore self-requested a review July 21, 2026 22:35

ninelore approved these changes Jul 21, 2026

View reviewed changes

nixpkgs-ci Bot added 12.approvals: 2 This PR was reviewed and approved by two persons. and removed 12.approvals: 1 This PR was reviewed and approved by one person. labels Jul 21, 2026

nixos/cosmic: migrate from gnome-keyring to oo7

71dadf0

salva09 force-pushed the cosmic-oo7-migration branch from d322c90 to e119c2d Compare July 22, 2026 00:37

nixpkgs-ci Bot added the 8.has: changelog This PR adds or changes release notes label Jul 22, 2026

nixos/cosmic: add oo7 migration to release notes

4dc1e59

salva09 force-pushed the cosmic-oo7-migration branch from e119c2d to 4dc1e59 Compare July 22, 2026 18:04

		services.gnome.gnome-keyring.enable = lib.mkDefault (lib.versionOlder lib.version "26.11");
		services.oo7.enable = lib.mkDefault (lib.versionAtLeast lib.version "26.11");

Uh oh!

Uh oh!

Conversation

salva09 commented Jul 9, 2026

Things done

Uh oh!

salva09 commented Jul 9, 2026

nixpkgs-review result

x86_64-linux

Uh oh!

nyabinary commented Jul 9, 2026

Uh oh!

Pandapip1 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Pandapip1 Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

caniko commented Jul 9, 2026

Uh oh!

salva09 commented Jul 9, 2026

Uh oh!

salva09 commented Jul 10, 2026

Uh oh!

salva09 commented Jul 10, 2026

Uh oh!

Uh oh!

Uh oh!

thefossguy commented Jul 10, 2026

Uh oh!

salva09 commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thefossguy commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

caniko commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

HeitorAugustoLN commented Jul 10, 2026

Uh oh!

salva09 commented Jul 10, 2026

Uh oh!

nyabinary commented Jul 10, 2026

Uh oh!

HeitorAugustoLN commented Jul 11, 2026

Uh oh!

ninelore left a comment

Choose a reason for hiding this comment

Uh oh!

salva09 commented Jul 21, 2026

Uh oh!

HeitorAugustoLN commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ninelore commented Jul 21, 2026

Uh oh!

`nixpkgs-review` result

`x86_64-linux`

Pandapip1 Jul 9, 2026 •

edited

Loading

salva09 commented Jul 10, 2026 •

edited

Loading

thefossguy commented Jul 10, 2026 •

edited

Loading

caniko commented Jul 10, 2026 •

edited

Loading

HeitorAugustoLN commented Jul 21, 2026 •

edited

Loading