No kbfs in CLI? about kbfs HOT 28 OPEN

The community/keybase package existed before we were shipping a GUI, and it hasn't been updated yet. It might be time to do that. @felixonmars is the maintainer; what do you think, Felix?

One of tricky points here is that our non-GUI client is just a go build, but our full GUI package requires a larger build script that includes among other things an npm install step. The script to do all this is in our repo, but we'll want to take a look at it and decide whether it's doing things that make sense for an official build. (For example, is it acceptable to pull packages from NPM at build time, without a bit-for-bit hash of what those packages are supposed to contain?) We'll also want to decide whether we want to make any changes to this script before other scripts we don't control in the Arch package tree take a dependency on it, or maybe whether we want to make an Arch-specific entrypoint to the build here. No big problems, I think, just points we'll want to think about.

from kbfs.

I think one of the reasons is it doesn't build KBFS binary at all. the Keybase Filesystem runs as a separate binary. On Linux/macOS, it's kbfsfuse.

I assume naively installing kbfsfuse in addition to community/keybase wouldn't be sufficient?

The /keybase path is non-standard and violates both FHS and Arch's packaging guidelines.

Does it need to be fixed? $XDG_DATA_HOME/keybase?

from kbfs.

@oconnor663 Thanks, I don't know why it didn't mount /keybase before. I tried it just now on my ssh session and it worked fine. Hum...

from kbfs.

Hi @OJFord -- I don't really follow. KBFS presents itself as a filesystem mount. If you've installed an official Keybase package, you should have a folder mounted at /keybase/ that you can manipulate with any normal shell/CLI commands.

from kbfs.

Thanks for the response, sorry that wasn't so clear.

The downloads page says:

Note: a community/keybase package exists but is currently command line only. If you want the full Keybase experience: yaourt -s keybase-bin

I'm totally fine with command line only, I just don't understand why it doesn't include the file system, even at the same version (1.0.17) as the GUI version was when I had it on a Mac.

from kbfs.

Thanks for the followup. We have no relationship with community/keybase -- likely that was built by some other individuals from our old code base that doesn't include the filesystem. Sounds like the yaourt way is what you want -- it will include both the GUI and the CLI (and the file system mount).

from kbfs.

Actually I could be wrong about the exact nature of community/keybase -- @oconnor663 would know more.

from kbfs.

Well, the latest version of keybase/client is 1.0.17, which is what I have.

It seems it's deliberately excluded; I'm just trying to understand why, or if that's permanent - or perhaps just a fixable oversight (hopeful!) :)

from kbfs.

Hmm, did you download that release from github and install from source? Or did you install the arch package via yaourt?

from kbfs.

@strib I installed it with pacman, the built-in Arch package manager.

The version with "full keybase experience" is in the AUR, i.e. a user contribution.

I'm just confused as to why the version number matches latest, but doesn't include KBFS, and I have to install a GUI (which doesn't yet do anything?) in order to use KBFS via the CLI.

from kbfs.

Ok thanks @OJFord. I don't know anything about the Arch packages. cc @oconnor663 @songgao.

The GUI is actually an important security component of KBFS -- it pops up windows telling you about the identity of the person you're sharing files with / reading files from. Without the GUI, we have no way to communicate that information to you through the file system interface.

It's possible to run KBFS in a GUI-less mode that is less secure, but I don't know how to do that in Arch exactly.

from kbfs.

@OJFord Hi Ollie! The keybase-bin on AUR is actually maintained by @oconnor663 , who is with Keybase. So please feel to use it! That's also what I use on my Linux laptop. The run_keybase takes care of bringing up both GUI and daemon service. I guess we are not ready for community repo yet. I'm not sure about the current community/keybase package, but will try to find out.

from kbfs.

Thanks @oconnor663, would be good to have it out of AUR.

Do you have any idea why the version number is latest, but it has no KBFS mount though? Is it simply that that it's not in go?

It's a fairly confusing UX at the moment, I think at least - "CLI only" to me doesn't imply lack of the filesystem; especially since it can't actually be used through the GUI at present anyway.

from kbfs.

@OJFord I think one of the reasons is it doesn't build KBFS binary at all. the Keybase Filesystem runs as a separate binary. On Linux/macOS, it's kbfsfuse.

from kbfs.

@oconnor663 Generally we want to avoid internet access during the build process. But here I have some more concerns:

• run_keybase has a hardcoded /opt path
• The GUI includes a bundled Electron. (We have an electron package, and have made atom depends on it)
• The /keybase path is non-standard and violates both FHS and Arch's packaging guidelines.

from kbfs.

I assume naively installing kbfsfuse in addition to community/keybase wouldn't be sufficient?

I wanted to do that until I saw strib's comment above: #309 (comment)

So basically the GUI needs to be included as part of the distribution.

$XDG_DATA_HOME/keybase?

That would be very nice, but the startup script will also need to deal with the creation of the directory, since we should not alter $HOME during installation.

from kbfs.

It's a fairly confusing UX at the moment, I think at least - "CLI only" to me doesn't imply lack of the filesystem

@felixonmars, could we update the description of the community package to explicitly say it doesn't include KBFS?

I assume naively installing kbfsfuse in addition to community/keybase wouldn't be sufficient?

You're right, @OJFord, it pretty much doesn't work. It's possible in theory to use KBFS without a GUI, but you run into hangs in common situations like "someone's proof is broken" or "you need to type in your password to unlock your secret keys", which the GUI would normally help you resolve. We're gradually getting rid of that second case, but there are others. In general this is something-that-will-someday-probably-work-but-which-requires-a-lot-of-design-attention-and-is-not-high-priority-right-now.

run_keybase has a hardcoded /opt path

That's helped us avoid having a lot of distro-specific logic in our scripts, but it's definitely something we could change.

The GUI includes a bundled Electron. (We have an electron package, and have made atom depends on it)

That sounds like the kind of thing that should be possible in theory too, though since it's almost certainly not possible on slower distros that don't have super-up-to-date Electron packages, I worry a little bit about the complexity of supporting both approaches. Also curious, do you know why a lot of existing AUR packages don't take that dependency (atom-editor-git, slack-desktop, visual-studio-code)?

The /keybase path is non-standard and violates both FHS and Arch's packaging guidelines.

Yeah, we knew this would be an issue when we decided to do it. The goal was to make paths as portable as possible (at least in the posix world). For example, say we have this file in our shared folder, using the current global /keybase root:

/keybase/private/felixonmars,oconnor663/our_secret_stuff.txt

If I message you that filepath, it'll probably just work when you paste it into some app's file-open dialog, or into the shell. However, if KBFS used a directory relative to $HOME, you could run into a couple different problems. In the best case, I see the path as

~/Keybase/private/felixonmars,oconnor663/our_secret_stuff.txt

which only sometimes works in your terminal (if it's not in quotes, and not in the middle of a --foo=... flag), and only sometimes works in app dialogs. Or worse, I see it as

/home/jacko/Keybase/private/felixonmars,oconnor663/our_secret_stuff.txt

which won't work on your machine at all.

We decided dealing with packaging and multi-user issues was worth it to avoid these sorts of paths. Anecdotally this seems to have been the right call so far, but here we are paying the piper :|

from kbfs.

in README.MD:

kbfs: A thin command line utility for interacting with KBFS without using a filesystem mountpoint.

but It seems it has been removed, maybe you can find it in old commits

from kbfs.

ok it seems in 3cf9045 kbfs has been renamed to kbfstool, but it didn't changed in README file.

from kbfs.

I'm not sure whether I should make a new issue or add it to this one. Forgive me if I should have made a new one.

My issue is:
Where is the simple CLI for mounting kbfs?

Do I need to use kbfsfuse? Do I need to learn how to start using the kbfstool?

I can login on keybase on CLI, but to mount my /keybase I need to use: run_keybase which is GUI only!
On systems like Qubes or remote SSH this isn't always desired/possible. Besides, sometimes I do only use a terminal without X to do my stuff.

from kbfs.

@RoCaKo some of the comments above are describing issues you'll run into if you try to run KBFS without the GUI, where normally the GUI would prompt you for something (like someone's proofs being broken), but the filesystem by itself can only hang. If you're ok with working through those issues, the run_keybase script will likely work for you. The GUI will fail to start, but since everything's getting started in the background, the script won't actually notice the failure. You can also take a look at the kbfsfuse command that the script is running, and run it yourself if you like.

from kbfs.

Hey Guys ,

im getting no kbfs found in the gui on windows 10 when i start a chat is there anything i can do to resolve the issue ?

from kbfs.

@evinhernandez it might be better to make a new issue over on github.com/keybase/client/issues, since this repo doesn't deal with the GUI at all. It would be good to also run keybase log send and post a log ID so we can help you debug it.

from kbfs.

@strib thanks i figured out the issue had to reboot my windows machine.

from kbfs.

For Arch Linux users, https://aur.archlinux.org/packages/keybase-headless-git/ might be useful. It contains Keybase core binaries and kbfs but no GUI.

I created this package as installing the Electron-based GUI takes too much disk space in terms of a 20GB VPS.

(#309 (comment))

The GUI is actually an important security component of KBFS -- it pops up windows telling you about the identity of the person you're sharing files with / reading files from. Without the GUI, we have no way to communicate that information to you through the file system interface.

I use kbfs to share files to others. I guess the CLI-only package is safe for this specific purpose :)

from kbfs.

I think it's safe, though you might run into inexplicable hangs if e.g. someone's Twitter proof gets deleted or whatever. @strib might be able to suggest a status file that you can cat, to have a shot at a meaningful error message when that happens?

from kbfs.

I think it would be an IO error on the command line, and not a hang. But still, when you read someone else's data for the first time, the popup would show you potentially valuable info about who they are. However, if you are always reading from someone you already have followed and trust, you should be fine.

from kbfs.

@felixonmars, could we update the description of the community package to explicitly say it doesn't include KBFS?

I'd rather add kbfs to the package, TBH. Actually, since it exists in a separate repo, and bloats the installation footprint by 40 MB (70 MB if you count the git remote protocol), and isn't actually needed for keybase usage, I would like to add it as a separate package. But I am currently waiting on a stable release that doesn't use the /keybase directory.

That's helped us avoid having a lot of distro-specific logic in our scripts, but it's definitely something we could change.

Would /usr/bin/keybase-gui be distro-specific? Funny, last I checked the whole world was literally full of non-distro commands that are not distro specific. I'm not sure what you are referring to here.

That sounds like the kind of thing that should be possible in theory too, though since it's almost certainly not possible on slower distros that don't have super-up-to-date Electron packages, I worry a little bit about the complexity of supporting both approaches. Also curious, do you know why a lot of existing AUR packages don't take that dependency (atom-editor-git, slack-desktop, visual-studio-code)?

AUR packages are unofficial by definition, and therefore they do this for the same reason the keybase-bin package does -- either because the AUR maintainer made a personal choice to go against distro packaging best practices, or because the software literally refuses to work that way for hysterical raisins.

This is not indicative of any sort of policy either in the official repos or in the AUR.

But I don't really see why it would be a problem to support both approaches. Surely, you need to build the app whether you repackage it in a prebuilt electron installation or not. You could offer e.g. /usr/bin/keybase-gui both as a symlink to /opt/keybase/Keybase, and a wrapper script running electron /usr/lib/keybase/ depending on how distro packagers handle things (and considering the monolithic nature of the packaging scripts, we will have to reimplement part of that logic anyway so no harm done, really).

If I message you that filepath, it'll probably just work when you paste it into some app's file-open dialog, or into the shell. However, if KBFS used a directory relative to $HOME, you could run into a couple different problems. In the best case, I see the path as

~/Keybase/private/felixonmars,oconnor663/our_secret_stuff.txt

which only sometimes works in your terminal (if it's not in quotes, and not in the middle of a --foo=... flag), and only sometimes works in app dialogs.

--foo ... without the equals sign works fine, and pathnames without spaces in them do not need to be quoted. Hopefully most people who are likely to do this via the shell rather than the Open In File Browser option of the gui, already know this.

I kind of feel those app dialogs should use e.g. python's os.path.expanduser() or else wordexp(3)

Of course this may be irrelevant as you've already separately made the decision to move to $XDG_DATA_HOME/keybase/fs, but I figured I'd mention it anyway. 😄

from kbfs.