Client: Feature request: WSL support in some form

[cerebrate]

I'm wanting for various reasons to (most prominently the ability to use a Keybase-encrypted git repository to store ssh keys, etc.) access Keybase and Keybase git repositories from inside the Windows Subsystem for Linux.

Trouble is, I can't do this: Keybase for Linux can't be installed under WSL (because of its dependency on FUSE, which WSL doesn't currently support), and in any case, it would be rather less than elegant to require two Keybase installs for a single machine.

Would it be possible to have a "keybase-proxy" package in some form which would pass through relevant calls to the running Windows keybase?

(Also, in the meantime, is there a workaround which would permit accessing a Keybase git repository using a supported schema in some manner, and/or to access the K: drive from within WSL? Attempting to mount it using DrvFs as a normal Windows drive fails:

# avatar @ ATHENA in ~ [11:27:46] C:1
$ sudo mount -t drvfs k: /mnt/k
mount: /mnt/k: wrong fs type, bad option, bad superblock on k:, missing codepage or helper program, or other error.
[1]    1444 exit 32    sudo mount -t drvfs k: /mnt/k

Thanks!

[cerebrate]

Addendum: At the moment I'm working around this by pushing the original WSL repository to a second repo in Windows space, then pushing that in turn to the Keybase repo, but that's a whole lot of workaround to use every time.

[cerebrate]

I tried a suggestion of symlinking /usr/local/bin/git-remote-keybase to the windows git-remote-keybase, but alas, no joy:

# avatar @ ATHENA in ~ [11:53:46]
$ git clone keybase://private/cerebrate/wsl-secrets
Cloning into 'wsl-secrets'...
Initializing Keybase... done.
Syncing with Keybase... done.
warning: You appear to have cloned an empty repository.

# avatar @ ATHENA in ~ [11:55:11]
$ cd wsl-secrets

# avatar @ ATHENA in ~/wsl-secrets on git:master o [11:55:22]
$ git status
On branch master

No commits yet

nothing to commit (create/copy files and use "git add" to track)

# avatar @ ATHENA in ~/wsl-secrets on git:master o [11:55:28]
$ touch test.txt

# avatar @ ATHENA in ~/wsl-secrets on git:master x [11:55:33]
$ git add .

# avatar @ ATHENA in ~/wsl-secrets on git:master x [11:55:37]
$ git commit -m "Test file"
[master (root-commit) 35fe2b8] Test file
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test.txt

# avatar @ ATHENA in ~/wsl-secrets on git:master o [11:55:48]
$ git status
On branch master
Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

nothing to commit, working tree clean

# avatar @ ATHENA in ~/wsl-secrets on git:master o [11:55:51]
$ git push
Initializing Keybase... done.
Syncing with Keybase... done.
Counting objects: git-remote-keybase error: (1) open objects: The system cannot find the file specified.
git-remote-keybase error: (1) open objects: The system cannot find the file specified.
error: failed to push some refs to 'keybase://private/cerebrate/wsl-secrets'
[1]    2276 exit 1     git push

[hwine]

FWIW, I have no trouble using keybase for git operations in wsl. The git protocol implementation doesn't need direct file access. (I.e. no dependency on fuse). I do have Keybase installed in both wsl & Windows.

$ keybase --version
keybase version 2.13.0-20181219142726+01e9fa19eb
$ git version
git version 2.17.1
$ lsb_release  -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:        18.04
Codename:       bionic

[rfgamaral]

@cerebrate Had the same issue today and instead of having Keybase installed in both Windows and WSL like @hwine I only have it installed in Windows unlike you and I solved my issue by creating the /usr/local/bin/git-remote-keybase executable (don't forget chmod +x) instead of an alias.

#!/bin/sh
git-remote-keybase.exe "$@"

It's working for me:

Ricardo@LP5J44QH2:/tmp$ git clone keybase://private/rfgamaral/dotfiles
Cloning into 'dotfiles'...
Initializing Keybase... done.
Syncing with Keybase... done.
warning: You appear to have cloned an empty repository.

[Kukunin]

@rfgamaral does it work for you with a non-empty repo? it fails for me with

Initializing Keybase... done.
Syncing with Keybase... done.
Counting: 5.86 MB... done.
Cryptographic cloning: (100.00%) 5.86/5.86 MB... done.
Checking connectivity... fatal: bad object 37f965b52acfe0b5d2aba55b4dd43a32a48fa234
fatal: remote did not send all necessary objects

If wonder if it's related with #12766

[rfgamaral]

@Kukunin Yeah, it doesn't for me either...

Tried to create a new repository, cloned it and commited/pushed an empty file:

Counting objects: git-remote-keybase error: (1) open objects: The system cannot find the file specified.
git-remote-keybase error: (1) open objects: The system cannot find the file specified.
error: failed to push some refs to 'keybase://private/rfgamaral/test-repository'

Probably related...

[strib]

@Kukunin @rfgamaral these errors are unrelated to the rest of this issue. Please open a new github issue and run keybase log send to get a log ID to include in the issue.

[rfgamaral]

@strib I'm not so sure it's unrelated. I mean, it's related to WSL because I just did the same steps as mentioned above ("Tried to create a new repository, cloned it and commited/pushed an empty file") directly in Windows (using git.exe inside cmd.exe) and it worked successfully:

Initializing Keybase... done.
Syncing with Keybase... done.
Counting objects: 211 bytes... done.
Preparing and encrypting objects: (100.00%) 211/211 bytes... done.
Counting refs: 41 bytes... done.
Preparing and encrypting refs: (100.00%) 41/41 bytes... done.
To keybase://private/rfgamaral/test-repository
 * [new branch]      master -> master

[strib]

@rfgamaral sorry I didn't mean to be dismissive. My impression was that this issue was about the installation of Keybase in WSL, not about the behavior of Keybase git under WSL and specific error messages it returns. I thought the "bad object" message was indicative of an error in the git format itself. But I was reminded of #12766 (a cygwin issue, still unsolved), and then you mentioned the same repo works outside WSL as well, so I'm not sure what's going on. I still don't know, sorry!

[rfgamaral]

@strib It's ok, no need to be sorry of anything.

The way I see it, this issue seems to be about how to use Keybase (especially the Git encrypted repos) inside WSL without installing Keybase for Linux inside WSL (because that's currently not possible).

Not sure how the user reporting that cygwin issue is using both things (Git and Keybase) but in my particular case I'm calling git <something> and that "git" is Git for Linux which will use "git-remote-keybase.exe" (a Windows binary). Due to WSL interop with Windows one can call .exe files inside WSL and they launch but maybe, somewhere in the middle, this "git linux" » "git-remote-keybase.exe windows" is causing the problem and might not be one easy to fix.

[rfgamaral]

maybe, somewhere in the middle, this "git linux" » "git-remote-keybase.exe windows" is causing the problem

I've tested a few things and I'm wondering about this because of paths. WSL paths are like linux /foo/bar and Windows expects paths like C:\foo\bar. Since git is a WSL binary and git-remote-keybase.exe is a Windows binary. One calls the other, somewhere in the middle, paths will not work.

Here's a verbose log:

Ricardo@LP5J44QH2:/tmp/tmp.QtHIaE4Bqs$ set -x; GIT_TRACE=2 GIT_CURL_VERBOSE=2 GIT_TRACE_PERFORMANCE=2 GIT_TRACE_PACK_ACCESS=2 GIT_TRACE_PACKET=2 GIT_TRACE_PACKFILE=2 GIT_TRACE_SETUP=2 GIT_TRACE_SHALLOW=2 git clone keybase://private/rfgamaral/test-repository -v -v; set +x+ GIT_TRACE=2
+ GIT_CURL_VERBOSE=2
+ GIT_TRACE_PERFORMANCE=2
+ GIT_TRACE_PACK_ACCESS=2
+ GIT_TRACE_PACKET=2
+ GIT_TRACE_PACKFILE=2
+ GIT_TRACE_SETUP=2+ GIT_TRACE_SHALLOW=2
+ git clone keybase://private/rfgamaral/test-repository -v -v
19:20:58.495155 git.c:418               trace: built-in: git clone keybase://private/rfgamaral/test-repository -v -v
Cloning into 'test-repository'...19:20:58.566514 run-command.c:643       trace: run_command: git-remote-keybase origin keybase://private/rfgamaral/test-repository
Initializing Keybase... done.
Syncing with Keybase... done. [442.0152ms] [memprof C:\Users\AmaralR\AppData\Local\Temp\mem.init.prof]Counting: 211 bytes... done. [17.9996ms] [memprof C:\Users\AmaralR\AppData\Local\Temp\mem.count.prof]
Cryptographic cloning: (100.00%) 211/211 bytes... done. [33.0015ms] [memprof C:\Users\AmaralR\AppData\Local\Temp\mem.clone.prof]
19:21:00.643953 run-command.c:643       trace: run_command: git rev-list --objects --stdin --not --all --quiet '--progress=Checking connectivity'19:21:00.679476 trace.c:377             setup: git_dir: /tmp/tmp.QtHIaE4Bqs/test-repository/.git
19:21:00.679727 trace.c:378             setup: git_common_dir: /tmp/tmp.QtHIaE4Bqs/test-repository/.git19:21:00.679801 trace.c:379             setup: worktree: /tmp/tmp.QtHIaE4Bqs
19:21:00.679863 trace.c:380             setup: cwd: /tmp/tmp.QtHIaE4Bqs19:21:00.679923 trace.c:381             setup: prefix: (null)
19:21:00.679991 git.c:418               trace: built-in: git rev-list --objects --stdin --not --all --quiet '--progress=Checking connectivity'
fatal: bad object f4692747bbd26ca19b734eed456f13cd856b082b19:21:00.681442 trace.c:477             performance: 0.007275000 s: git command: /usr/lib/git-core/git rev-list --objects --stdin --not --all --quiet '--progress=Checking connectivity'fatal: remote did not send all necessary objects
19:21:00.738171 trace.c:477             performance: 2.243053000 s: git command: git clone keybase://private/rfgamaral/test-repository -v -v+ set +x

I don't know exactly what git-remote-keybase.exe does but my best guess is that it's using Linux based paths (ie: /tmp/tmp.QtHIaE4Bqs/test-repository/.git) while running on Windows, thus the failure.

The way I see it, our only solution would be to run Keybase for Linux inside WSL, but like OP said:

Trouble is, I can't do this: Keybase for Linux can't be installed under WSL (because of its dependency on FUSE, which WSL doesn't currently support), and in any case, it would be rather less than elegant to require two Keybase installs for a single machine.

Right now, I don't think there's a way around the FUSE dependency. If there were, mantaining two Keybase installs would be cumbersome but it would suffice as a workaround. You could always try to build some sort of proxy for that, similar to what we currently do to run Docker inside WSL (more info: https://nickjanetakis.com/blog/setting-up-docker-for-windows-and-wsl-to-work-flawlessly - basically, we install Docker for Linux under WSL and configure the Docker inside WSL to actually communicate through a socket with the Docker for Windows). But I digress...

[strib]

Thanks for investigating!

What exactly is stopping the installation of keybase for linux? Usually with package managers there is an option to override the dependencies and force the installation anyway. If you can do that, you might as well try it. The FUSE bits are not required for git, so it might just work.

[rfgamaral]

@strib Just tried and was able to install Keybase inside Linux with the official instructions on the website:

curl -O https://prerelease.keybase.io/keybase_amd64.deb
sudo dpkg -i keybase_amd64.deb
sudo apt-get install -f
run_keybase

All dependencies are successfully installed (even fuse, but I don't think it works) and everything is working. For testing, I created a Git encrypted repository inside WSL (in a Windows accessible directory, like my Windows user folder), pushed some files, cloned the same repo inside Windows, pushed some files there and pulled the changes inside WSL. Everything worked seamlessly.

It's not my case but we can have multiple WSL installations in one system (Debian, Ubuntu, Kali and others) and for each one, a new device registration will be needed. I have a home PC and a work laptop and both have a single WSL installation so for me that's 2 extra devices. It's the major downside to this I guess.

The way around this would be to have something like I mentioned before in how Docker for Linux works, it connects to the Docker engine running Windows through a socket. Not sure if something like this could be implemented in Keybase, if it even makes sense and how much work it would be (I can imagine a lot).

The second way around I can think of (albeit with a downside of it's own) would be for git-remote-keybase.exe to handle path translation (assuming that's the problem), for instance:

> wsl wslpath -w '/mnt/c/Users'
C:\\Users

More information about the wslpath tool can be found here: https://github.com/MicrosoftDocs/WSL/releases/tag/17046

The downside to this, as I previously mentioned, is that this would only work if the Git repositories are located inside a Windows accessible folder. Meaning, this will never work:

> wsl wslpath -w '/opt/my_git_repo'
wslpath: /opt/my_git_repo: Result not representable

Can't think of anything else to solve or work around this issue in a more elegant way.

[zanderz]

UPDATED: still testing

[rfgamaral]

I'm confused, you seem to have two different git executables. What is that /cmd/git?

When you run git inside WSL, which git version is running? I think you're running Git for Windows which successfully communicates with Keybase for Windows.

The problem exists while using Git for Linux which doesn't communicate properly with Keybase for Windows (more specifically git-remote-keybase.

[zanderz]

WHOOPS please disregard the above experiments, I wasn't in wsl at all, I was in the git bash shell. My mistake! Will test further.

[zanderz]

OK, the filesystem mount just plain won't work. But there are a couple of ways to make git repos work without a separate Linux keybase installation.

One way is to remove the Linux git and add an alias to Windows git.exe from the WSL side.

Another way is to establish links on the Windows side:

cd %localappdata%\Keybase
mklink keybase keybase.exe
mklink git-remote-keybase git-remote-keybase.exe

These seem to make those commands available on the WSL side.

[rfgamaral]

One way is to remove the Linux git and add an alias to Windows git.exe from the WSL side.

For me this is not an option. I don't want to deal with Git for Windows, my goal is to have dev tools like this solely installed in WSL and use that as my dev environment.

cd %localappdata%\Keybase
mklink keybase keybase.exe
mklink git-remote-keybase git-remote-keybase.exe

These seem to make those commands available on the WSL side.

This alone doesn't work either since the problem was never making keybase.exe or git-remote-keybase.exe available on the WSL side (there's many ways one can achieve that).

The problem is mixing things up, like Git Linux binaries with Keybase Windows binaries, they are running under different contexts and expect different path formats.

But your post and all this writing gave me an idea that I've tested and it seems to work, just create an alias similar to this one:

alias kgit='/c/Users/AmaralR/Downloads/PortableGit/bin/git.exe'

When I need to work with Keybase encrypted repositories I use kgit (Windows version which communicates with Keybase on Windows) and when I want to work with common Git repositories I use git (the Linux/WSL version).

It's not ideal, it still requires Git for Windows to be installed in the host machine (which I personally would like to avoid but it's an alternative for people that don't mind that). But there's also another downside to this method, it will only work correctly if the working directory is a Windows mountable path, like /c/. For instance, take a look at this example:

Ricardo@LP5J44QH2:~$ cd $(mktemp -d)
Ricardo@LP5J44QH2:/tmp/tmp.jGBPUk1Eeg$ ll
total 0
Ricardo@LP5J44QH2:/tmp/tmp.jGBPUk1Eeg$ kgit clone keybase://private/rfgamaral/test-repository
Cloning into 'test-repository'...
Initializing Keybase... done.
Syncing with Keybase... done.
Counting: done.
Cryptographic cloning: done.
Ricardo@LP5J44QH2:/tmp/tmp.jGBPUk1Eeg$ ll
total 0
Ricardo@LP5J44QH2:/tmp/tmp.jGBPUk1Eeg$ cd /c/Users/AmaralR/test-repository/
Ricardo@LP5J44QH2:/c/Users/AmaralR/test-repository$ ll
total 0
-rw-r--r-- 1 Ricardo Ricardo 15 Jan 16 09:52 README.md
Ricardo@LP5J44QH2:/c/Users/AmaralR/test-repository$ cat README.md
Hello Keybase!
Ricardo@LP5J44QH2:/c/Users/AmaralR/test-repository$

What happened here is that I'm using kgit which is actually Git for Windows running inside WSL but I'm trying to clone to a path that Windows does not have access to. The clone didn't fail, but it didn't clone to /tmp/tmp.jGBPUk1Eeg either, instead, it cloned to my Windows home folder /c/Users/AmaralR/test-repository as a "fallback". But as long as you are inside /c/, it will work as expected.

Personally, I have all my Git repositories (encrypted or not) located inside my Workspace so this is not a problem for me:

Ricardo@LP5J44QH2:~$ ll total 0 lrwxrwxrwx 1 Ricardo Ricardo 26 Jan 12 00:48 Workspace -> /c/Users/AmaralR/Workspace/

To conclude, it would be nice if somehow git-remote-keybase.exe could be aware of WSL and if it's running in a Windows shell or a WSL shell and translate the paths accordingly, this would avoid a double Git installation (Windows and WSL) for people that would like to have just one under WSL.

[cerebrate]

No longer necessary, since WSL2 should support Linux keybase natively.

[rfgamaral]

@cerebrate I don't think this should be ignored because WSL2 is announced. If we don't care for WSL1 support, we are forcing everyone to use WSL2. But Microsoft said they will support both WSL1 and WSL2 because they work differently and one does not necessarily replace the other. Until WSL2 deprecates WLS1, support for Keybase under WSL1 would still be nice.

[bkarakashev]

@strib Just tried and was able to install Keybase inside Linux with the official instructions on the website:

curl -O https://prerelease.keybase.io/keybase_amd64.deb
sudo dpkg -i keybase_amd64.deb
sudo apt-get install -f
run_keybase

All dependencies are successfully installed (even fuse, but I don't think it works) and everything is working. For testing, I created a Git encrypted repository inside WSL (in a Windows accessible directory, like my Windows user folder), pushed some files, cloned the same repo inside Windows, pushed some files there and pulled the changes inside WSL. Everything worked seamlessly.

It's not my case but we can have multiple WSL installations in one system (Debian, Ubuntu, Kali and others) and for each one, a new device registration will be needed. I have a home PC and a work laptop and both have a single WSL installation so for me that's 2 extra devices. It's the major downside to this I guess.

The way around this would be to have something like I mentioned before in how Docker for Linux works, it connects to the Docker engine running Windows through a socket. Not sure if something like this could be implemented in Keybase, if it even makes sense and how much work it would be (I can imagine a lot).

The second way around I can think of (albeit with a downside of it's own) would be for git-remote-keybase.exe to handle path translation (assuming that's the problem), for instance:

> wsl wslpath -w '/mnt/c/Users'
C:\\Users

More information about the wslpath tool can be found here: https://github.com/MicrosoftDocs/WSL/releases/tag/17046

The downside to this, as I previously mentioned, is that this would only work if the Git repositories are located inside a Windows accessible folder. Meaning, this will never work:

> wsl wslpath -w '/opt/my_git_repo'
wslpath: /opt/my_git_repo: Result not representable

Can't think of anything else to solve or work around this issue in a more elegant way.
I am getting this error:
KBFS failed to FUSE mount at /keybase: fusermount: exit status 1
Any idea how to resolve that?

[bkarakashev]

@strib Just tried and was able to install Keybase inside Linux with the official instructions on the website:

curl -O https://prerelease.keybase.io/keybase_amd64.deb
sudo dpkg -i keybase_amd64.deb
sudo apt-get install -f
run_keybase

All dependencies are successfully installed (even fuse, but I don't think it works) and everything is working. For testing, I created a Git encrypted repository inside WSL (in a Windows accessible directory, like my Windows user folder), pushed some files, cloned the same repo inside Windows, pushed some files there and pulled the changes inside WSL. Everything worked seamlessly.

It's not my case but we can have multiple WSL installations in one system (Debian, Ubuntu, Kali and others) and for each one, a new device registration will be needed. I have a home PC and a work laptop and both have a single WSL installation so for me that's 2 extra devices. It's the major downside to this I guess.

The way around this would be to have something like I mentioned before in how Docker for Linux works, it connects to the Docker engine running Windows through a socket. Not sure if something like this could be implemented in Keybase, if it even makes sense and how much work it would be (I can imagine a lot).

The second way around I can think of (albeit with a downside of it's own) would be for git-remote-keybase.exe to handle path translation (assuming that's the problem), for instance:

> wsl wslpath -w '/mnt/c/Users'
C:\\Users

More information about the wslpath tool can be found here: https://github.com/MicrosoftDocs/WSL/releases/tag/17046

The downside to this, as I previously mentioned, is that this would only work if the Git repositories are located inside a Windows accessible folder. Meaning, this will never work:

> wsl wslpath -w '/opt/my_git_repo'
wslpath: /opt/my_git_repo: Result not representable

Can't think of anything else to solve or work around this issue in a more elegant way.

I am also getting this error: ERROR dial unix /home/blago/.config/keybase/keybased.sock: connect: no such file or directory

When I try to keyabse login

[cerebrate]

Just to note: works great and with all features on WSL2, especially when combined with a suitable means of getting systemd up and running.

(As far as I know, WSL 2 is the only option for FUSE support, since it requires a Linux kernel driver and WSL 1 doesn't have the necessary kernel.)

[rfgamaral]

@cerebrate Just to be sure, this will add the WSL2 instance as an extra device on your account, correct?

[cerebrate]

@rfgamaral Yes, it will (I named it "hostname-wsl"). Not ideal, I suppose, but at least everything works.