Closed vanyasem closed 5 years ago
I haven't tried bash on Windows yet. Should give it a go when I'm playing with the new chocolatey builds.
You can PM me on Telegram @vanyasem
or on Matrix @vanyasem:matrix.mynameisivan.ru
if you need any assistance
I can't make it work in Windows either. Using the WSL is the only way I've found to install pass. No luck with passff
either so @vanyasem , I would really appreciate if you could point me to some indications on this!
I don't think this is realistic to fix. Issues I could see: 1) you need to specify a binary, a command with multiple options does not work. You get something partially working if you create a gpg.bat with this content: C:\Windows\System32\bash.exe --login -c "/usr/bin/gpg %" 2) That works for some things, but e.g. for decrypting you need to pass a path to gpg. That path is however a Windows path. While a wslpath command to convert them exist, it's not easy to use 3) A lot of commands, in especially "pass" itself needs environment variables to be set up. I don't think these get passed from Windows to WSL at all currently, and even if they were there is the whole wslpath issue. The closest I got to, which works on the command-line but not when used programmatically is a pass.bat with this: C:\Windows\System32\bash.exe --login -c "PASSWORD_STORE_DIR=$(wslpath '%PASSWORD_STORE_DIR%') /usr/bin/pass %" 4) I don't think stdin/stdout is properly passed between WSL and ordinary programs, so this probably just can't work. Then again I might be wrong, as using the gpg.bat wrapper DOES work for listing keys?!
@rdoeffinger Pext (issue mentioned above) implemeted support for pass in WSL. It DOES work. So, well, all of your points are invalid.
I never said it's not possible (except maybe in point 4, but I also said I might be wrong). It just seems to need a large number of tricky hacks/fixes and even more debug time. The .bat files implement mostly what Pext did for its fixes. Though maybe the problem is actually running .bat files, maybe it would indeed work if running these commands directly? But then, how should these be handled in the UI? Such complex command wrappers do not really work well with how the settings only expect a binary path currently.
I suspect another issue is that for password-protected keys QtPass currently relies on gpg making use of graphical password input plugins, but those won't be available when running pass in WSL. Correct me if I miss some reason why that's not a problem though.
@rdoeffinger You just get pass as it was running on GNU/Linux. It gives you the same output, and it communicates with gpg by itself. The only thing required is to make QtPass support calling it "the Windows way". I have no idea how GPG or UI changes are related at all.
You won't be able to request a password, so the only limitation is that a GPG key should have an empty keystore. Which is a bummer, and probably has a solution, but that's none of my business, I don't run Windows.
It happens that I wanted this for other reasons. There were some nasty issues (some not even related to WSL support), and I haven't even tried keys with password. But see merge request #416
Was this implemented or was it just discarded?
This has been implemented in #431 and is currently being improved on in project: No OS left behind
TODO:
@annejan that's great! thanks!
QtPass refuses to work with
pass
running in Bash on Windows (tried Ubuntu and Arch GNU/Linux)I specified
C:\Windows\System32\bash.exe --login /usr/bin/pass
for a path to pass (which works withpassff
for example), but QtPass refuses to accept that setting and tries to use native Git/GPG