Client: Using the client without starting the GUI

[dkasak]

Previously basic commands like keybase encrypt worked without depending on KBFS and/or starting the GUI, neither of which are included in the Arch Linux keybase package. Recently, though, trying to encrypt a file complains about KBFS not running.

% touch foo
% keybase encrypt -i foo -o foo.enc dkasak
▶ ERROR Keybase services aren't running - KBFS client not found. On Linux you need to start them after an update with `run_keybase` command.

The run_keybase command is not included in the Arch Linux package, though. I've tried installing keybase-bin from the AUR for comparison, but in addition to starting the KBFS service, run_keybase also runs the GUI application. Therefore, it doesn't seem to be possible to use Keybase from the shell without starting the GUI anymore. Am I missing something? Also, what's the reason for the new KBFS dependency? It seems the encrypt command should still be able to work without it.

[dkasak]

Sorry for bumping this, but even a short response to this would be greatly appreciated. I loved using keybase for the identity infrastructure it provides, but if using it from the terminal without the GUI isn't going to be supported, I'll have to move back to plain old gpg.

[maxtaco]

Cc @oconnor663

TLDR try keybase pgp encrypt

On Sat, Oct 21, 2017 at 10:07 AM Denis Kasak [e-mail]
wrote:

Sorry for bumping this, but even a short response to this would be greatly
appreciated. I loved using keybase for the identity infrastructure it
provides, but if using it from the terminal without the GUI isn't going to
be supported, I'll have to move back to plain old gpg.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/8662#issuecomment-338401532,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA05_9XSYqr5cJ5ux5rrfMDXhTR7fVS1ks5sufqsgaJpZM4PkPce
.

[dkasak]

Thanks. I know about keybase pgp encrypt, but it's not a 1-to-1 replacement since, for example, it complains that there's no encryption subkey when I try encrypt for a colleague (presumably because he only uploaded the signing subkey of his PGP key to Keybase, somehow). Also, even if I managed to work around this, another piece may break in the future. So I guess my question was more along the lines of – is using Keybase from the terminal something that will be supported or can I expect that it will gradually degrade in functionality when used without the GUI?

[maxtaco]

Sorry am pecking at my phone and am away from computer. You can also use
the v1 flag for encrypt. Or can also start up kbfs without GUI or fuse.
And we are working on changing this too.

More via @oconnor663

On Sat, Oct 21, 2017 at 11:36 AM Denis Kasak [e-mail]
wrote:

Thanks. I know about keybase pgp encrypt, but it's not a 1-to-1
replacement since, for example, it complains that there's no encryption
subkey when I try encrypt for a colleague (presumably because he only
uploaded the signing subkey of his PGP key to Keybase, somehow). Also, even
if I managed to work around this, another piece may break in the future. So
I guess my question was more along the lines of – is using Keybase from the
terminal something that will be supported or can I expect that it will
gradually degrade in functionality when used without the GUI?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/8662#issuecomment-338410817,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA05_yPj5IOP7FGg58IoOzYPiZ1BNCxaks5sug9kgaJpZM4PkPce
.

[oconnor663]

Hey @dkasak, here's a quick version of what happened. Previously keybase encrypt would use your device secret keys, and the device public keys of your recipients, to bootstrap encryption. However, this had the huge downside that encrypted messages weren't decryptable on new devices that you provisioned after sending the message. About six months ago, we took a dependency on KBFS's key distribution machinery, and that solved the future devices problem at the expense of requiring kbfsfuse to be running. In the future, we'll probably switch to a yet newer piece of machinery that we've built for team keys, and doing that will remove the kbfsfuse dependency (and also let you encrypt a message for an entire team, including future members). That's not on our front burner though -- it might be a few months.

The community/keybase package on Arch has definitely bitrotted some -- in part because we don't control the PKGBUILD for that one. That said, we do plan on supporting GUI-less keybase in general. Probably we'll spend some time slicing up the current keybase-bin package, maybe by having the other parts take a dependency on community/keybase. I'm not sure how that's going to shake out.

If you want to prevent the GUI from starting in the meantime, one quick hack would be to comment out the line that starts it in the run_keybase script.

[dkasak]

@oconnor663, thanks for the info. I'm very glad to hear that the CLI tool is going to be supported without depending on the GUI. I've already reported the bug on community/keybase upstream, but it hasn't been fixed so far.

In the meantime, I've figured out that keybase encrypt --current-devices-only ... seems to satisfy my use case, at the obvious expense of it being non-decryptable on my other devices.

Once you've moved to the new team machinery you mentioned, do you think CLI keybase will still require the run_keybase script or is that something you can't tell right now? Also, do you mind if we leave this bug open until the hack is unnecessary?

[oconnor663]

keybase encrypt --current-devices-only should be decryptable on your _existing_ other devices (not just the one you wrote it on), but not the future ones, I think.

The big source of uncertainty with run_keybase is that we're still figuring out exactly how we want to integrate with systemd. It might be that everything starts working with socket activation.

We can keep this bug open, though unfortunately our close-bugs-when-we're-done-with-them hygiene isn't great...

[dkasak]

Any progress on this? Has the situation changed?

[oconnor663]

We now have substantial systemd integration on systems that support it (though we don't actually use socket activation). So if you wanted to systemctl --user enable keybase.service, for example, you can do that now. You can see a lot of changes in the run_keybase script.

[dkasak]

Thanks. I'll try to push things along to see whether this could be integrated in the Arch package since it still excludes everything besides the keybase executable.

[oconnor663]

That should work in theory. That said, I think that Arch community package is currently the only thing in the world that installs /usr/bin/keybase without the rest of our system, and I'm worried that the usefulness of that binary by itself is going to go down over time.

[drathir]

The best point why old legacy version is probably still used by lot of ppl its not need running in background all the time which is really useful...

[eli-schwartz]

So, this should not be a problem anymore now that I added kbfs to the Arch repos.

What would make it easier, is if keybase started kbfs.service in the background the same way it currently starts keybase.service in the background. At least when it tries to demand the existence of KBFS...

That should work in theory. That said, I think that Arch community package is currently the only thing in the world that installs /usr/bin/keybase without the rest of our system, and I'm worried that the usefulness of that binary by itself is going to go down over time.

This seems much less impressive when people realize that Arch community package(s) is the only thing in the world, other than your own self-hosted builds, that installs any part of the keybase system. :stuck_out_tongue:

AFAIK the binary should be useful for most keybase-related things even without kbfs installed as well, or am I missing something?

[rcorre]

@eli-schwartz thanks!

I initially encountered the same error:

[rodencor@heredesk ipaas]$ keybase chat send rcorre
▶ ERROR Unable to find conversation.
When considering rcorre as a username or a list of usernames, received error: failed to open chat conversation: Keybase services aren't running - KBFS client not found. On Linux you need to start them after an update with `run_keybase` command..
When considering rcorre as a team name, received error: Team "rcorre" does not exist.

Installing kbfs and running systemctl --user start kbfs resolved it.

AFAIK the binary should be useful for most keybase-related things even without kbfs installed as well, or am I missing something?

Possibly this?

About six months ago, we took a dependency on KBFS's key distribution machinery, and that solved the future devices problem at the expense of requiring kbfsfuse to be running

Given this, keybase might be pretty useless without kbfs as well.

[eli-schwartz]

Yes, I know that specific functionality does not work. That hardly makes the whole thing useless without KBFS. Maybe I could expand the optdepends description to include a reference to encrypt.

[rcorre]

Makes sense. I saw chat as the primary functionality. Setup is still pretty straightforward with the separate keybase and kbfs packages.

[eli-schwartz]

Or, alternatively, I think the Keybase team may be considering merging kbfs into the client itself rather than developing them separately. Would make it less likely that they forget to release new kbfs versions alongside the client, but we'll see how closely they want to tie the two together.

[oconnor663]

We would like to merge the repos at some point. I don't think we ever plan to merge the processes, though, since the kbfsfuse process needs to own a FUSE mount.

Edit: Could it make sense to merge the packages? I don't have strong feelings about that part. Presumably the only thing people care strongly about is the option to install a package with no GUI dependencies?

[dsifford]

@heronhaye Update?

[heronhaye]

@dsifford Encrypting with the options

keybase encrypt  --no-self-encrypt --no-device-keys --no-paper-keys -m "hello" <recipient>

(i.e., just your recipients "entity-keys")

will encrypt with the recipient's per user key (https://keybase.io/docs/teams/puk) which can be decrypted by their future devices as well. It also doesn't require KBFS to be running. As the name implies, it will not encrypt for yourself.

Additionally, in a forthcoming Linux release, run_keybase will have the option to start up without the gui (i.e., just keybase and kbfs). I can post a link to the docs here when that's out.

If you're using systemctl, which Arch uses, you can already control keybase, kbfs, and keybase.gui independently, though kbfs depends on keybase, and the gui depends on both.

[dsifford]

Additionally, in a forthcoming Linux release, run_keybase will have the option to start up without the gui (i.e., just keybase and kbfs). I can post a link to the docs here when that's out.

That would be great

If you're using systemctl, which Arch uses, you can already control keybase, kbfs, and keybase.gui independently, though kbfs depends on keybase, and the gui depends on both.

I am using systemctl on Arch actually. Goal is to be able to run the daemon on startup without the gui popping up. Is this currently possible?

[heronhaye]

I am using systemctl on Arch actually. Goal is to be able to run the daemon on startup without the gui popping up. Is this currently possible?

Yes, (and this will be documented too), you have to do is disable the autostart entry in your desktop environment's startup manager (there will also going to be a keybase command for this), and then systemctl --user enable keybase. And optionally systemctl --user enable kbfs. If you're running on a server, you may want to loginctl enable-linger so it keeps running after your ssh session ends.

[eli-schwartz]

It's been possible for a long time, just systemctl --user enable keybase.service and it will be set to start on login like any other user service. One of @heronhaye's pending improvements is that it will soon automatically create the kbfs mountdir if it does not exist yet.

This specific issue is obsolete due to my having packaged kbfs itself in Arch.

[dsifford]

@eli-schwartz I have that enabled, but on boot it launches the GUI.

kbfs.service                        disabled
keybase.gui.service                 static
keybase.service                     enabled

Would disabling keybase.service and enabling kbfs.service do what I'm looking for? I just want to be able to use the command line to sync files. I never use the GUI ever.

[heronhaye]

@dsifford, are you using a desktop environment? Gnome, KDE, or XFCE, maybe? There's an autostart file in ~/.config/autostart/keybase_autostart.desktop. Try adding

Hidden=true
X-GNOME-Autostart-enabled=false

to the end of that file.

[eli-schwartz]

I'm guessing it got separately started by the .config/autostart/ file which the GUI creates in the background. It is then your desktop environment, not systemd, which starts the GUI. (That being said, the GUI does launch using systemd, but by a one-time starting of the service, not by enabling it.

[dsifford]

Aha.. that sounds like it could be it... Thanks so much @heronhaye @eli-schwartz. :pray:

[heronhaye]

No problem. Please make a new issue if you have any more questions or bug reports.