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 ***@***.***> 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 <#8662 (comment)>, 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 ***@***.***> 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 <#8662 (comment)>, 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. 😛

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.