Need to document how to share keys between Win and WSL

[jamiehankins]

If I follow your example, I get a WSL GnuPG configuration that redirects the Cygwin sockets at %APPDATA%\gnupg to %LOCALAPPDATA%\gnupg as UDS. It sets the WSL GNUPGHOME to the LOCALAPPDATA one. At that point, a simple command like gpg --card-status will work. However, anything that needs keys won't. This, for example: gpg --list-secret-keys --keyid-format LONG jamie.hankins@gmail.com.

gpg-agent has the ability to redirect the sockets. That would give us the ability to share the home directory without the two kinds of sockets stepping on each other. Unfortunately, that code is excluded by this in assuan-socket.c in libassuan: #ifndef HAVE_W32_SYSTEM. That means that the key information has to be in the same directory as the Cygwin sockets.

The way I got around this was by creating directory symlinks for openpgp-revocs.d and private-keys-v1.d, and by hard-linking trustdb.gpg and pubring.kbx.

Here's what I put together to do this:
set LOCALGNUPG=%LOCALAPPDATA%\gnupg if not exist %LOCALGNUPG% mkdir %LOCALGNUPG% cd %LOCALGNUPG% mklink /D .\openpgp-revocs.d %APPDATA%\gnupg\openpgp-revocs.d mklink /D .\private-keys-v1.d %APPDATA%\gnupg\private-keys-v1.d mklink /H .\trustdb.gpg %APPDATA%\gnupg\trustdb.gpg mklink /H .\pubring.kbx %APPDATA%\gnupg\pubring.kbx

I'm firmly in the "knows enough to be dangerous" camp on this. If possible a little guidance in the readme on how this really should be configured would be helpful.

Also, gpg commands on WSL show this warning:
gpg: WARNING: unsafe permissions on homedir '/mnt/c/users/jamie.hankins/AppData/Local/gnupg'

A little digging says I can fix this by applying some permissions. That doesn't seem to do it. I'm guessing that "chmod" on a Windows directory doesn't do much. Is there a known way to fix this?

Apologies for the long rambling ticket.

[rupor-github]

Apologies for not paying enough attention to WSL1 :) I am sure there are different ways of going about it and I would love to hear and learn about them - I am not an expert on GPG and I surely do not use WSL1 often any more...

I do not think what you are doing is a good idea - each WSL linux distro should have it's own keys database. Sharing physical files directly with windows is not what I wanted to achieve. So if you look at my example fro WSL1 it sets GNUPGHOME - to point to the properly wrapped gpg-agent sockets from the Windows end and to indicate a place where WSL1 gpg will create its databases. That surely results in "unsafe permission" warning as windows directory would be used instead of "~/.gnupg". This in my case was easily remedied by applying something like

chmod 600 /mnt/c/Users/mike0/AppData/Local/gnupg/*
chmod 700 /mnt/c/Users/mike0/AppData/Local/gnupg

on it.

Now - the case of empty gpg -K - my understanding is that when remoting gpg socket you supposed to import public keys at each remote point anyways. That is what referred in the guide linked at the end of readme as "Copy the public half of your keys to the remote machine". This way when needed gpg will use redirected socket to get "private" part while keeping it "secure".

Things are slightly different with how ssh keys are distributed because ssh-agent protocol is different.

You could probably achieve something similar by actually redirecting socket from "AppData/Local/gnupg" to "~/.gnupg" using the same socat trick as WSL2 does but lifetime maintenance could be a bit of a hassle.

Hope it helps.

[jamiehankins]

Believe me, as helpful as this tool is, you've got nothing in the world to apologize for!

We're using WSL 1 because of the ease and speed it has with accessing Windows files. We build multiple things and need to be able to shift back and forth on the same code tree on our dev machines. The point of all of this for us is to be able to do signed commits from the Linux side. Of course, it's easy enough to just do all the commits from the Windows side if we need to.

I'll read up more on copying the public keys. We don't keep any private keys on the hard drive. They're all on YubiKeys, so just copying the public half should be enough, and I'm guessing it will generate the database from that.

I tried "chmod"ing the home directory, but I'm guessing that it doesn't actually do anything on Windows drives. It's just an annoyance, though, nothing real to worry about.

While I've got your attention, I've got a feature suggestion for the pin entry tool. Adding the option for entering the pin on a secure desktop would be nice. (example here: https://codingvision.net/c-create-secure-desktop-anti-keylogger).

I would do this as a PR for you as a thank you, but I've never written a line of Go. Maybe it would be a nice way for me to dip my feet in it. :-)

[rupor-github]

I am afraid that protocol design for data exchange between gpg and pinentry makes secure desktop a bit of overkill, at least in my view. If you are trying to minimize probability of keylogging - would allowing pinentry "remembering" password data in windows credential manager help or it does not work with YubiKey? I am not really sure yet how "secure" the whole gpg approach is - but this is much wider discussion I guess.

As for chmodding windows files - this somehow works for me

but you could always move home directory or use socat trick to have database inside Linux home directory.

[rupor-github]

Installed WSL1 Debian and validated - with properly set GNUPGHOME directory (either pointing to AppData or AppData subdir symlinked as ~/.gnupg seems to be functioning properly: after importing public keys git signing works from inside WSL1 distro. I updated README in several places highlighting this fact.