Fish shell + WSL2 + gnome-keyring / secret-tool

config.fish

#
# This fish config sets up a working `gnome-keyring` on WSL2.
# I imagine it will work with WSL1 as well, perhaps after adjusting the `DISPLAY` value.
#
# Based off this bash script: https://askubuntu.com/questions/815327/running-gnome-keyring-on-wsl-windows-subsystem-for-linux
# Tested and working with `aws-vault` and `jetbrains-toolbox`.
#

# Be sure your x server is running!!!
set -x DISPLAY (cat /etc/resolv.conf | grep nameserver | awk '{print $2}'):0

pgrep dbus-daemon > /dev/null

if test $status -eq 1
  dbus-launch --sh-syntax | read --line bus_address ignored bus_pid bus_windowid

  set -Ux DBUS_SESSION_BUS_ADDRESS (string match -r "'(.*)'" $bus_address)[2]
  set -Ux DBUS_SESSION_BUS_ID (string match -r "=(.*);" $bus_pid)[2]
  set -Ux DBUS_SESSION_BUS_WINDOWID (string match -r "=(.*);" $bus_windowid)[2]
end

# pgrep limited to 15 chars, so truncate `daemon`
pgrep gnome-keyring-d > /dev/null

if test $status -eq 1
  gnome-keyring-daemon | read --line gnome_keyring_control ssh_auth_sock

  set -Ux GNOME_KEYRING_CONTROL (string split -m 1 = $gnome_keyring_control)[2]
  set -Ux SSH_AUTH_SOCK (string split -m 1 = $ssh_auth_sock)[2]
end

Another way is to use https://github.com/oh-my-fish/plugin-foreign-env/ to parse the environment variables from bash. I've used it like this:

fenv "eval `dbus-launch`"
fenv "eval `gnome-keyring-daemon -r -d -c secrets,ssh,pkcs11`"

There's pros and cons with either solution I think, I didn't want to manually parse or hard code the outputs from starting the two daemons.

Thanks for the reference to fenv! That seems preferable to me as well.

A neat trick to unlock the default keyring upon opening the terminal (unless it already is) is:

# Unlock GNOME keyring if necessary
# Requires having run: secret-tool store --label='Unlock hook' unlock unlock
secret-tool lookup unlock unlock > /dev/null

(When you store the dummy unlock secret, it will ask for a password. Put whatever you want. You will never need to enter it.)

This works by querying the default keyring for a known entry. If the keyring is locked, gnome-keyring will request that you unlock it.

I renamed the keyring created by PhpStorm to login.keyring, so system tools think it's a login keychain. Works nicely, though!

I also set up Seahorse. Install seahorse and:

# Ensure seahorse saves passwords
set -x SSH_ASKPASS /usr/lib/seahorse/ssh-askpass

I like this more than Keychain, as now I'm down to one password entry per WSL 2 startup. I might try setting up https://github.com/jstarks/npiperelay using the trick on https://github.com/rupor-github/wsl-ssh-agent to use the Windows ssh-agent. But that has nothing to do with gnome-keyring-daemon. I'd have to comment out the line setting SSH_AUTH_SOCK.

I have some more tips for fellow tmux users:

1. If you use tmux-resurrect and have a command tmux new-session -d in your config.fish, make sure it's near the end, or at least after setting the environment variables in this gist. It took me a while to figure out why the SSH agent never worked until I manually killed dbus-launch and gnome-keyring-daemon and sourced config.fish again.
2. Use this snippet if you want to share the state among tmux sessions. tmux automatically shadows the universal variables with global copies when it imports the parent session's environment variables, so the global copies have to be unset in order to use the correct values from the top-level session (the universal variables). I'm a little proud of this one :)

if set -q TMUX
  # Unset conflicting global variables.
  set globalsToUnset DBUS_SESSION_BUS_ADDRESS DBUS_SESSION_BUS_ID DBUS_SESSION_BUS_WINDOWID GNOME_KEYRING_CONTROL SSH_AUTH_SOCK
  set globals (set -gx | cut -d' ' -f 1)
  for var in $globalsToUnset
    if contains -- $var $globals
      set -e $var
    end
  end
end

This means: if we're inside tmux, get the names of all global variables, loop over them, and unset any in our list ($globalsToUnset).

Using backticks is legacy syntax for making system calls. Consider $(...) instead.

http://mywiki.wooledge.org/BashFAQ/082

I start Sway directly from the console with no display manager. I start Gnome Keyring Daemon with a systemd user unit that ships with the Arch Linux gnome-keyring package.

To set the environment variables, I have this in ~/.config/fish/config.d/999-sway.fish:

# If running from tty1 and a graphical session has not already been started, start Sway
set TTY1 (tty)
if status --is-login && test "$TTY1" = "/dev/tty1"  && test -z $WAYLAND_DISPLAY

  # gnome-keyring prints bash-style env vars when starting, namely SSH_AUTH_SOCK
  # fenv will use bash to eval that output and then convert the "foreign environment"
  # a native Fish environment
  fenv "eval $(gnome-keyring-daemon --start)"
  set --global --export DESKTOP_SESSION "sway"
  set --global --export TERMINAL "foot"
  set --global --export _JAVA_AWT_WM_NONREPARENTING 1
  set --global --export QT_AUTO_SCREEN_SCALE_FACTOR 1
  set --global --export QT_QPA_PLATFORM wayland
  set --global --export QT_WAYLAND_DISABLE_WINDOWDECORATION 1
  set --global --export MOZ_ENABLE_WAYLAND 1
  set --global --export MOZ_WEBRENDER 1
  set --global --export MOZ_ACCELERATED 1
  set --global --export BEMENU_BACKEND wayland
  set --global --export GTK_THEME "Adwaita:dark"

  # DON'T use exec so that environment variable inheritance works correctly.
  # We name this script with the 999 prefix because the sway execution blocks and no other scripts
  # will run until after it exits.
  /sbin/sway
end