kbfsfuse should behave better when keybase is in locked state about kbfs HOT 9 OPEN

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?

from kbfs.

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.

from kbfs.

Sent debug logs, ID is: dc9cb24182a74b68109b7b1c

from kbfs.

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.

from kbfs.

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?

from kbfs.

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 [email protected]
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
.

from kbfs.

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.

from kbfs.

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 [email protected]
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
.

from kbfs.

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?

from kbfs.