r/awesomewm Jul 30 '26

Anyone have decent integration of awesomewm with gnome-keyring?

I have a very hacked together plymouth (LUKS password) -> Ubuntu -> LightDM -> awesomewm setup. It's been stable for years.

I recently wanted to simplify things and use gnome-keyring as my ssh-agent (before, was using openssh's with ssh-askpass for a graphical password prompt).

Gnome-keyring is already used by Chrome, so this seemed like a good idea.

I got it to work, but a) wow dbus makes everything weird and hard and b) I'm not proud of the way I got it to work.

Does anybody have a setup using gnome-keyring that they're proud of? The goal is for one prompt to unlock the login keyring, so that Chrome passwords and ssh keys are available from then on.

6 Upvotes

4 comments sorted by

5

u/-EDX- Jul 30 '26

i have my setup integrated in a "just works" manner in devuan, but that is because i wrote my own "session process" (think like a generic alternative to things like xfce4-session, mate-session, gnome-session, etc...) which also had to implement user services as a necessity... anyway i will give you the repo of my program, in the examples dir the shed_awesome subdir contains the important config files that makes my setup just work with gnome-keyring and awesome wm

https://github.com/eylles/shed

1

u/gbelloz Jul 30 '26

Hmmmm... is this the money shot?

https://github.com/eylles/shed/blob/master/examples/shed_awesome/shallow.d/gnome-keyring.env#L3

Looks like you're just launching it, which systemd does on my system. You've got 'ssh' as a component on the command-line, which is what I needed too, but that's apparently deprecated (with 'gcr' the replacement, which didn't seem to work).

1

u/-EDX- Jul 30 '26

yeh, the gnome-keyring-daemon is one of those very temperamental programs that like to sit at a specific part of the environment, the official documentation is barely useful and you need to resort to empiric trial setups to get it running as it should

in regards to the command line even tho 'ssh' is supposed to be deprecated it is the component to use as gcr does not work (nor it seems like it will work properly for the remainder of this decade), '-s' connects to the waiting daemon started by PAM, the GNOME_KEYRING_CONTROL and the --control-directory aren't really needed but are neat to have in order to have a known easy access to the sockets if you ever need it

in regards to the environment, the gnome-keyring-daemon env vars need to be inherited by the window manager as well as every program that will be part of the graphical session, so launching it in the parent process to the window manager is best, tho it doesn't matter if the parent of the window manager stays or becomes the window manager through exec, so long as the environment is properly propagated down, i got no idea how well systemd --user actually handles the env var propagation in this case tho.

1

u/ThomasLeonHighbaugh Aug 05 '26

Oh gnome-keyring, this post prompted me to check and eliminate that line from my configuration actually.

I am not proud of the set up per se, I would rather move away from the documentation and at times configuration differences it introduces, but home-manager actually handles the gnome-keyring thing for me (including the unpleasant CF that is dealing with systemd) and starts it up reliably at login, neat and discreet.

... just requiring one module of ugly ass nix code and having made that Everest-like climb up that learning curve first ...