First pass at Windows support #29
Conversation
|
Hi @neersighted great work. ServiceYour implementation leaves some open questions which I'm still digging around with in my own implementation. How to support demonized running within windows. During my research I've found two possible options:
I tend towards the first option as this avoids having a service and a "client" component and the service handling on windows is also quiet different to linux, whereas the program needs to handle some specific interface/api to be a service instead of just a program which is handled from the outside. Also a service runs in the context of a windows specific user by default which enables other users on the same system to connect to the service. Therefore there must exist a system which avoids access for the wrong person. WSLFor the part of WSL support IMHO I would leave this to external tooling instead of supporting it directly within yubikey-agent. At least for now it's always required to have another component running/launched to access from within WSL. I've merged support for this kind of scenario within https://github.com/BlackReloaded/wsl2-ssh-pageant where it's able to talk to the windows named pipe. By the way which pinentry utility are you using? I'm not comfortable with relying to have gpg installed on the machine in order to have a |
| flag.Usage() | ||
| os.Exit(1) | ||
| if runtime.GOOS == "windows" { | ||
| *socketPath = "\\\\.\\\\pipe\\\\openssh-ssh-agent" |
There was a problem hiding this comment.
I would avoid hardcoding the path where the pipe is implemented. If someone wants to customize it, there should exist a way to do it. Similar to Mac and Linux.
There was a problem hiding this comment.
I think you might be misreading this line -- this is meant to set a default on Windows only (the flag is required on Unix systems). Maybe it would be better to set a default up above in the flag section instead.
There was a problem hiding this comment.
You’re right I screwed this up. Sorry for the hassle.
|
Thanks for the feedback, @tobiaskohlbau! I'm not sure on the daemonization part yet -- I was planning on leaving that up to the user, for the most part. I'm reasonably sure a text mode program can be run through task scheduler with no UI -- otherwise, I'll have to do some more digging. I was figuring that would be an exercise left to the reader for now. WRT WSL, I am quite familiar with wsl2-ssh-pageant as I currently use it for SSH and GPG. I would myself prefer to have something in this repo, as part of the goal of this project is for it to be turnkey, and WSL represents a major platform these days. Having an integrated, seamless solution seems quite advantageous for adoption. Also, existing solutions that use I'm currently using |
|
Thank you for doing this! I can't really test the Windows code myself, but if it's reasonably self-contained I'd be very happy to merge it. Here are some guidelines:
Ping me once you've rebased and it's ready for review and I'll get to it quickly (this time ^^). |
|
Hi, what's the status on this? I got it running, except that the first connection attempt always fails with |
|
Closing in favor of #69. |
Hey, this is a quick-and-dirty windows PoC. I'm not sure how you want to go about structuring the program in the long run, so for now everything still lives in
main.I have plans to add a single-binary (but dual process) WSL proxy component -- some guidance on how you want to proceed there layout/abstraction-wise would be welcome (my thoughts are a
cmd/yubikey-agentand acmd/yubikey-agent-wslthat only builds on Windows).Big thanks to @tobiaskohlbau for getting a hard-to-track-down buffer bug fixed in upstream gopass.