Client: Can't access my public files on Linux or keybase.pub

[smiller171]

I can't access my public files on Linux or keybase.pub, which has brought down my site smiller.keybase.pub.

I can access files on my Mac, but on Linux I see:

➜  ~ keybase fs ls /keybase/public/smiller171
▶ ERROR Error checking merkle tree: tried 100 roots, but seqno not found

[smiller171]

Just submitted logs which also had errors.

▶ INFO ignoring UI logs: context deadline exceeded
Hint: You are currently not seeing messages from other users and the system.
      Users in the 'systemd-journal' group can see all messages. Pass -q to
      turn off this notice.
No journal files were opened due to insufficient permissions.
▶ ERROR Error reading logs: Journalctl exited with an error: exit status 1


------------
Success! Your log ID is:

  08d5535fd3033f797d59461c

Here's a URL to submit new bug reports containing this ID:

  https://github.com/keybase/client/issues/new?body=[write%20something%20useful%20and%20descriptive%20here]%0A%0Amy%20log%20id:%2008d5535fd3033f797d59461c

Thanks!
------------

I'm submitting from a Chromebook using Crostini, but since I can't access from keybase.pub either the issue isn't Chromebook specific. (I didn't log in on the Chomebook until after the issue appeared)

[maxtaco]

Thanks @smiller171. I see the bug, it'll take us a little while to fix it. We'll follow up with you. Sorry for the inconvenience!

[maxtaco]

BTW, we have two fixes coming out for this problem, the first fix might solve it, which should be out sooner. Thank you.

[strib]

keybase/kbfs#1597 should fix this once it's merged. (Though it won't fix the underlying issue, which will still happen if the last write to a folder happens to have been from a revoked device that got unlucky w.r.t. the global merkle tree. @maxtaco is going to work on that fix soon.)

[smiller171]

@strib sounds like currently the answer to avoid this is to write to the directory from a different device before revoking a device? If I make a new write to the folder from my Mac will that restore access?

[strib]

@strib sounds like currently the answer to avoid this is to write to the directory from a different device before revoking a device? If I make a new write to the folder from my Mac will that restore access?

The current problem is because one of the devices you revoked in February got unlucky, and the revoke operation itself got stuck in a long line of server operations. (We expect there to be only one or two server operations in between when you click "revoke" and the server confirms it, but in this case there were more than 300.) However, this was not the device that last wrote to your public folder, that was the other device you revoked in February. Usually Keybase clients only need to run the (currently buggy) verification process for the device that actually did the last write, but due to a _different_ bug, it was doing them on _all_ revoked devices, and hitting a problem with the key that didn't do the write.

So in short, no, writing from your Mac won't help current Linux clients, because they will still be verifying all your keys unnecessarily. keybase/kbfs#1597 stops them from verifying all keys, which will fix the issue as soon as I get it reviewed by someone and merged.

If the folder happened to have been written last by the problematic key, then yes writing to it from a different device before revoking would fix it. But you shouldn't have to change your behavior to adapt to our bugs, so I would just go about business as usual, and we'll fix the bugs ASAP.

[smiller171]

Is there any reason that keybase.pub should have only just now run into this issue when the revocations were a while ago? Was one of these bugs only recently introduced?

Also, my current behavior is to revoke devices after I reformat/wipe them, Is it better to just leave them as they are since the private key data can't be retrieved anyway?

[strib]

Is there any reason that keybase.pub should have only just now run into this issue when the revocations were a while ago? Was one of these bugs only recently introduced?

Yes, the bugs were introduced by us this week. We are tightening checks on data written by revoked keys, and there are a few corner cases, like this one, that we messed up.

Also, my current behavior is to revoke devices after I reformat/wipe them, Is it better to just leave them as they are since the private key data can't be retrieved anyway?

I think it's always better to revoke devices that won't get used again.

[strib]

There's a new linux build out with a fix, and https://smiller171.keybase.pub/ works again. Please close this out if everything looks ok on your end. Thanks, and sorry for the inconvenience.

[smiller171]

Thanks for getting a fix out so fast! I'll take a look shortly

[heronhaye]

Closing as resolved, please make a new issue if you still have trouble, thanks!