[Windows] WSL integration possible using some extra tools

@ag_Christian is there any way to follow updates for this?

We have plans to bring support for Windows Unix Domain Sockets to the built-in SSH agent

Hey there, @ere,

We're currently waiting on upstream support from one of the Rust libraries we use. Their tracking issue can be found here, on GitHub. If this stagnates for too long, we'll most likely consider a different option though. Assuming they add support for this, we will try to quickly push out a new 1Password version which takes advantage of it.

Thanks for checking in with us on this feature!

@ag_Christian Is there any update regarding 1Password CLI integration in WSL? I have tried manually forwarding the "//./pipe/1Password-1-1Password-BrowserSupport" from Windows to WSL using a combination of socat and npiperelay but the socket got forcibly closed. This is most likely due to the CLI security model https://developer.1password.com/docs/cli/biometric-security/#technical-design and the pipe was opened from an unauthenticated app (npiperelay).

I also have tried using the Windows version of 1Password CLI running under WSL but it is plagued by https://1password.community/discussion/131565/windows-cli2-crashes-30-of-the-time-go-error making it very unreliable.

Hey there,

I've successfully added Github SSH via 1Password on cmd.exe, but fail to do so in WSL2 (ubuntu).
I've followed the outlined steps:
- npipereleay accessible from path in Windows
- socat installed in WSL

However, WSL doesn't get access to my keys in 1P. Can someone tell my what's wrong with this setup?
```
$ ssh mailto:git@github.com:
mailto:git@github.com: Permission denied (publickey).

$ git pull:
error: unsupported value for gpg.format: ssh
fatal: bad config variable 'gpg.format' in file '/home/jannik/.gitconfig' at line 2
``
When I remove thegpg.format = ssh` in WSL, I get no error while pulling but still can't ssh to mailto:git@github.com

My .gitconfig at "C:\Users\\.gitconfig" and "~/.gitconfig" is the same:

[gpg]
format = ssh
[gpg "ssh"]
program = C:\\Users\\<user>\\AppData\\Local\\1Password\\app\\8\\op-ssh-sign.exe
[commit]
gpgsign = true
[user]
signingkey = ssh-ed25519
name = username
email = email@gmx.de
[core]
editor = \"C:\\Users\\<user>\\AppData\\Local\\Programs\\Microsoft VS Code\\bin\\code\" --wait
sshCommand= C:/Windows/System32/OpenSSH/ssh.exe



$ socat UNIX-LISTEN:$SSH_AUTH_SOCK,fork EXEC:"npiperelay.exe -ei -s //./pipe/openssh-ssh-agent",nofork &
[1] 3305
2022/09/11 14:43:23 socat[3304] E "/home/<user>/.ssh/agent.sock" exists


Hey @startcook1e it's possible there are other things going on, but for the error you're seeing (unsupported value for gpg.format: ssh) a good place to start would be to upgrade your Git version to https://developer.1password.com/docs/ssh/git-commit-signing#requirements as this was when SSH commit signing was introduced.

Hey @startcook1e i was able to sign the commit just by changing the pgp ssh program to windows using its mount point

[user]
email = my-email@provider.com
name = My Name
signingkey = public key
[gpg]
format = ssh
[gpg "ssh"]
program = /mnt/c/Users/MyUser/AppData/Local/1Password/app/8/op-ssh-sign.exe
[commit]
gpgsign = true

I hope you can do it

I tried @aislandener config and now get this error instead, not sure what file it cannot find
```
❯ git commit
error: Error: AppError { error: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }, location: Location { file: "ssh\op-ssh-sign\src\main.rs", line: 30, col: 13 } }

fatal: failed to write commit object
```

Hi @ag_Christian, @jody.h_1P, is this solution using npiperelay and socat considered acceptable from a security perspective?

@teh_c, is this solution still working for you?

Hey everyone,

To start, I have no update into "official" support for the integration, sorry.

Regarding the security of it, @tghosth, I don't believe it would be too much less secure then if we built it into 1Password for Windows ourselves. The only thing that comes to mind is that another process could utilize the trust 1Password applies to the proxy process to allow that other, unintended, process to use the SSH key without approval. Whether or not this is a true security problem is heavily dependent on your own threat model.

Additionally in the feature's experience, you may lose is contextual information or longer-lasting approvals by proxying the messages (which only have "public" data in them) through some relay process on your system.

Still waiting on the Rust library issue mentioned above being fixed? Given the (lack of) progress in the referenced issue looks like we need to wait some more time.... In my company it would be much easier to use the solution built into an already "cleared for use" product than trying to get some tool (npiperelay) from github approved for use.