kbfsfuse should behave better when keybase is in locked state

[krillr]

Currently if kbfs is running and keybase has not been unlocked, the kbfs will get stuck in an error loop which does not recover when keybase is unlocked. Error loops like this shouldn't happen, and I think kbfs should run "keybase unlock" or similar when an access to /keybase is attempted but keybase is in a locked state. This would improve user-friendliness and make kbfsfuse more useful as a system service.

[strib]

That is certainly not intentional. If your device key is locked, kbfs operations are supposed to trigger a pinentry popup, and also should immediately proceed on an unlock event. Can you describe more about the situation where you saw this (what platform, etc) and provide a keybase log send ID?

[krillr]

Sure thing:

I am running Arch Linux on a Dell XPS 9550, I am running keybase from the keybase-bin AUR package.

$ keybase --version
keybase version 1.0.16-20160808160043+cc9784a
$ kbfsfuse --version
1.0.2-20160808160043+750ab25

I am using the i3 window manager, and have it execute the following when my session starts:

keybase -d --log-file="$logdir/keybase.service.log" service &>> "$logdir/keybase.start.log" &
kbfsfuse -debug -log-file="$logdir/kbfsfuse.service.log" /keybase &>> "$logdir/kbfsfuse.start.log" &

I'll wrap up what I'm doing here and start a fresh session, then send along some logs.

[krillr]

Sent debug logs, ID is: dc9cb24182a74b68109b7b1c

[krillr]

Not sure if that also shares the kbfs debug output, so i've shared that log here: http://tinyurl.com/jglbohv

You'll see it starts out unable to sign or encrypt anything, and says it'll "retry" -- but the pin never pops. I manually unlock with "keybase unlock" and it is able to issue commands (including sharing this log file). This time it didn't lock up like it has in the past, which is interesting. I'll try to better repro that here soon.

[strib]

Hi @krillr -- in your above command it seems you aren't starting the Keybase GUI manually, unless you left out a line. (The GUI log in your log send ends on 8/14.) That would mean there would be no pinentry, at least for the timeline in the log send.

Also, in the manual kbfs log you sent, it does connect and start working! As of this line:

2016-08-20T21:57:00.357805 ▶ [DEBU kbfs connection.go:380] 083 (CONN MDServerRemote a6c82e97) Connection: connected

After that, you'll see a bunch of successful file system operations. But since there's not a corresponding service log for those times, I can't really tell hat caused it to work. Is it possible you just weren't running a GUI when it wasn't working?

[krillr]

As I said in my post with the KBFS logs, it started working after I
manually ran the "keybase unlock" command. This pops up the same pinentry
dialog that gpg uses, I type in my PW, and it goes. I'll resend the keybase
logs here in a bit.

On Sun, Aug 21, 2016 at 7:29 AM, Jeremy Stribling notifications@github.com
wrote:

Hi @krillr https://github.com/krillr -- in your above command it seems
you aren't starting the Keybase GUI manually, unless you left out a line.
(The GUI log in your log send ends on 8/14.) That would mean there would be
no pinentry, at least for the timeline in the log send.

Also, in the manual kbfs log you sent, it does connect and start working!
As of this line:

2016-08-20T21:57:00.357805 ▶ [DEBU kbfs connection.go:380] 083 (CONN MDServerRemote a6c82e97) Connection: connected

After that, you'll see a bunch of successful file system operations. But
since there's not a corresponding service log for those times, I can't
really tell hat caused it to work. Is it possible you just weren't running
a GUI when it wasn't working?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#270 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAqCO0xtIlOseLxnBSbLgrVMhcWWkVdvks5qiGDYgaJpZM4JpORw
.

[strib]

Oh sorry, I misread your post. Sure, if you can get logs with a repro that would be great. I would expect a keybase unlock to allow kbfs to continue if the device key is locked. And if you're running the Keybase GUI, and kbfs attempt to access the key should cause a Keybase pinentry to pop up.

[krillr]

Keybase should probably try and pop up whatever pinentry program is
available, and not rely solely on the key base GUI? I don't see any good
reason why keybase needs a specialized pinentry setup, especially when
keybase unlock uses the standard gpg-provided one.

On Sunday, August 21, 2016, Jeremy Stribling notifications@github.com
wrote:

Oh sorry, I misread your post. Sure, if you can get logs with a repro that
would be great. I would expect a keybase unlock to allow kbfs to continue
if the device key is locked. And if you're running the Keybase GUI, and
kbfs attempt to access the key should cause a Keybase pinentry to pop up.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#270 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAqCOyRsBLjLdksbpdhKRCuRFZKqZezwks5qiKz1gaJpZM4JpORw
.

[strib]

I believe we had a reason for that but I can't recall what it was. @patrickxb @maxtaco do you remember why we don't use gpg pinentry when kbfs requests a secret key?