3 ms·

All fair points, i was a bit hasty with my comment. Do you mind sharing your configs for gnome keyring with sway? I'm on sway and would love to use that.

jchw 3y ago
Here's a simplified version of what I have now. let dbus-sway-environment = pkgs.writeShellScript "dbus-sway-environment.sh" '' ${pkgs.dbus.out}/bin/dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP=sway ${pkgs.systemd.out}/bin/systemctl --user stop pipewire wireplumber xdg-desktop-portal xdg-desktop-portal-wlr ${pkgs.systemd.out}/bin/systemctl --user start pipewire wireplumber xdg-desktop-portal xdg-desktop-portal-wlr ''; in { services.gnome.gnome-keyring.enable = true; programs.sway.extraSessionCommands = '' export GNOME_KEYRING_CONTROL=/run/user/$UID/keyring export SSH_AUTH_SOCK=/run/user/$UID/keyring/ssh ''; etc."sway/config".text = '' # ... exec --no-startup-id ${dbus-sway-environment} exec --no-startup-id ${pkgs.dex.out}/bin/dex -a # ... ''; } I believe all of this is necessary. Now in my case, I have a bit more going on, but I think most of it is no longer needed. In the past it was significantly worse in my configuration :) How this works: 1. When you set services.gnome.gnome-keyring.enable, you get a few things. It sets security.pam.services.login.enableGnomeKeyring which gives you the PAM modules needed to start gnome-keyring and pass it the password on login. It also sets up some systemd and DBus services, which are necessary for gnome-keyring to work right. 2. GNOME_KEYRING_CONTROL and SSH_AUTH_SOCK need to be set for things to work right. I traced down where they're supposed to get set in GNOME, but I don't remember why it did not work for SwayWM: I think things happened in the wrong order. So, I set them manually. 3. `dbus-sway-environment` is supposed to ensure that the DBus environment for the user session is updated with the graphical environment. I found this necessary for a number of things to work correctly. It's possible this isn't needed for gnome-keyring anymore, but it might still be. In the past I was using custom systemd user services to run the components of gnome-keyring in which case it really was needed. 4. Finally, dex. `dex -a` launches XDG Autostart applications. This is handy because when you set services.gnome.gnome-keyring.enable, several XDG Autostart applications get installed for the different modules of gnome-keyring. SwayWM itself, being a WM, does not start autostart applications, and in fact, you may not even want this behavior in general, in which case you should adjust it to explicitly start just the few keyring applications you might want. In case you don't know, the reason why both PAM and dex start gnome-keyring is because when PAM starts gnome-keyring, it's running in a sort-of bootstrap mode: it basically just exists to store the password temporarily, then the autostart modules take over later. addendum: I set XDG_CURRENT_DESKTOP=sway explicitly because my XDG_CURRENT_DESKTOP is normally Unity to trick Electron and other apps into using libappindicator. It may not be necessary to do this anymore, but I haven't tried to see what happens.
- colordrops 3y ago
  This is amazing, thank you for putting in the effort to document this.

jchw 3y ago

Here's a simplified version of what I have now. let dbus-sway-environment = pkgs.writeShellScript "dbus-sway-environment.sh" '' ${pkgs.dbus.out}/bin/dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP=sway ${pkgs.systemd.out}/bin/systemctl --user stop pipewire wireplumber xdg-desktop-portal xdg-desktop-portal-wlr ${pkgs.systemd.out}/bin/systemctl --user start pipewire wireplumber xdg-desktop-portal xdg-desktop-portal-wlr ''; in { services.gnome.gnome-keyring.enable = true; programs.sway.extraSessionCommands = '' export GNOME_KEYRING_CONTROL=/run/user/$UID/keyring export SSH_AUTH_SOCK=/run/user/$UID/keyring/ssh ''; etc."sway/config".text = '' # ... exec --no-startup-id ${dbus-sway-environment} exec --no-startup-id ${pkgs.dex.out}/bin/dex -a # ... ''; } I believe all of this is necessary. Now in my case, I have a bit more going on, but I think most of it is no longer needed. In the past it was significantly worse in my configuration :) How this works: 1. When you set services.gnome.gnome-keyring.enable, you get a few things. It sets security.pam.services.login.enableGnomeKeyring which gives you the PAM modules needed to start gnome-keyring and pass it the password on login. It also sets up some systemd and DBus services, which are necessary for gnome-keyring to work right. 2. GNOME_KEYRING_CONTROL and SSH_AUTH_SOCK need to be set for things to work right. I traced down where they're supposed to get set in GNOME, but I don't remember why it did not work for SwayWM: I think things happened in the wrong order. So, I set them manually. 3. `dbus-sway-environment` is supposed to ensure that the DBus environment for the user session is updated with the graphical environment. I found this necessary for a number of things to work correctly. It's possible this isn't needed for gnome-keyring anymore, but it might still be. In the past I was using custom systemd user services to run the components of gnome-keyring in which case it really was needed. 4. Finally, dex. `dex -a` launches XDG Autostart applications. This is handy because when you set services.gnome.gnome-keyring.enable, several XDG Autostart applications get installed for the different modules of gnome-keyring. SwayWM itself, being a WM, does not start autostart applications, and in fact, you may not even want this behavior in general, in which case you should adjust it to explicitly start just the few keyring applications you might want. In case you don't know, the reason why both PAM and dex start gnome-keyring is because when PAM starts gnome-keyring, it's running in a sort-of bootstrap mode: it basically just exists to store the password temporarily, then the autostart modules take over later. addendum: I set XDG_CURRENT_DESKTOP=sway explicitly because my XDG_CURRENT_DESKTOP is normally Unity to trick Electron and other apps into using libappindicator. It may not be necessary to do this anymore, but I haven't tried to see what happens.

colordrops 3y ago
This is amazing, thank you for putting in the effort to document this.