Client: Files need to be rekeyed, open on other device

[OJFord]

In what seems to be a similar issue to #3286, I'm unable to access my /keybase/private/ojford directory.

I reinstalled macOS, installed Keybase - the same version, 1.0.17, as before.

Where this differs from #3286 is that I used a _pre-existing_ paper key to verify; did not generate a new one nor revoke any.

I did revoke some prior devices that were just previous installations on this same laptop (an annoyance I've raised in #4260) but not the paper key.

After I successfully enter the paper key, it says it's rekeying the private directory. But even hours later if I try to open it, it says I need to open "on one of [my] other computers to unlock". I've never had any others - just old installations on this laptop; I've now revoked all but one of them - I don't see that it's useful but I kept one just in case.

[maxtaco]

Yeah, seems like an issue. Can you provide a keybase log send? We'll take a look

Cc: @strib and @jzila and @aalness and @patrickxb

[strib]

Already looking in the server...

[strib]

@OJFord it looks like that folder is not keyed for your paper key. It was last updated on 8/8, but your paper key was created on 8/13. Do you remember the circumstances around when you created your paper key? Have you run KBFS on a non-revoked device since then?

The folder _is_ keyed for your device agilis, so if you can possibly boot up KBFS as agilis, it should rekey for your new device (and the paper key) to give you access.

[OJFord]

Ah, damn. I know what happened - I switched to Arch, authenticated Keybase and must have revoked 'old' paper keys and generated new one. I didn't have KBFS because despite running the latest version of Keybase, didn't have a GUI and therefore not the filesystem (keybase/kbfs#309).

I then changed my mind, switched it back to macOS, and continued with the new paper key - though using it for the first time with KBFS.

Obviously I still have my GPG keys - is that not sufficient to decrypt? (Seems odd..)

Huge thanks for the fast response by the way, really appreciate that! :)

[strib]

Ahh, that makes sense. Sadly no we don't encrypt files for PGP keys, only for the ECC keys created for devices and paper keys.

Are you able to boot up agilis?

[OJFord]

agilis is a previous installation on the same device unfortunately.

Will revoke it now, and be super careful with paper keys! I need to dig a bit deeper to understand this better - this came about because I'd assumed that as long as I had my PGP keys and Keybase credentials I was good to go; actually it's also required to _always_ have an active device with KBFS support, or a paper key that has been used ('keyed'?) against KBFS.

How do I 'reset' and rekey against the device and paper key that I currently have?

[strib]

@OJFord I'm not sure how you reinstalled the device, but maybe there's a chance your secret key for agilis is still around somewhere? If you're on Linux, look in ~/.config/keybase/ and see if multiple devices are listed in config.json?

[OJFord]

I wiped the disk, so no.

Luckily I didn't have anything irreplaceable in there though.

[strib]

As for your other questions: it's tough to give a simple answer on the requirements. As soon as you add a new device or paper key, any live existing device running KBFS will rekey it for that new device. If there's no time period when KBFS is running on the old device after the new device is added, but before you revoke the old device, you will lose your data.

We probably need to make this clearer in the revoke process, if you are at risk for losing data. I think we have enough info to figure that out. @maxtaco is there a ticket/plan for that?

Unless you want to reset your whole Keybase account, we can manually reset the folder for you (losing the data inside forever). If you want me to do that, please run the following command on one of your devices, and substitute the current date and time as indicated:

keybase sign -m "<DATE_AND_TIME>: Please completely reset folder /keybase/private/ojford because I no longer have access to any of the devices it is keyed for."

and post the output here. Thanks!

[maxtaco]

@oconnor663 worked on that feature last. I think there is backend support
for it that electron might not have plumbed through. But maybe we need CLI
support too.

Cc @malgorithms

On Wednesday, September 14, 2016, Jeremy Stribling [email protected]
wrote:

As for your other questions: it's tough to give a simple answer on the
requirements. As soon as you add a new device or paper key, any live
existing device running KBFS will rekey it for that new device. If there's
no time period when KBFS is running on the old device after the new device
is added, but before you revoke the old device, you will lose your data.

We probably need to make this clearer in the revoke process, if you are at
risk for losing data. I think we have enough info to figure that out.
@maxtaco https://github.com/maxtaco is there a ticket/plan for that?

Unless you want to reset your whole Keybase account, we can manually reset
the folder for you (losing the data inside forever). If you want me to do
that, please run the following command on one of your devices, and
substitute the current date and time as indicated:

keybase sign -m ": Please completely reset folder /keybase/private/ojford because I no longer have access to any of the devices it is keyed for."

and post the output here. Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/4279#issuecomment-247162968,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA05_yPHdhBQPztTkA2G0nsFj1Cq7wsLks5qqGjzgaJpZM4J9OIQ
.

[OJFord]

@strib

BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5wcIkHbrzxh
KIp yW31id7uwAtmXMW pVP5zEFhPhF2IZD OiBzAojAC236tg8 Hz3fY5ZUiVUIkA5 9TTg9NX325MHwSH SXkKaPFU7PCt5Lm 2KurrIQ9B4rIlsf ax1ZtG1ihivP8Nd QmlzX0SnL5iOLl8 fOnydybSvCIgiSq 1VSVPv85qynP0qZ VNTZf9AeSRgiIbU Um9Dg7dLgiiyoqN WbsRdg6CU1GYREP 0ODLVafL7lOcAkb 2H2OI0sinHFiFn5 sk14UF1feIw5Zm2 QqSx6EEtNFK6fzd aO2cTFPLRrRsK1q rNBSmFj59hd3R0k LLcnyoRu011bkqQ LnDIx8o6AY6Xxfd gcVbgKifzrYOxF2 Ci3PgSTLIzsy7gL irGaXc5uNcXOUPt NO4pQCU7QliNiLY LLBtsRbdWfJS7sS u5JAtfR4DrCvL7y iajcuRJohoP84wX Ih4iXpEhKOnz3d4 sOVm0JRA. END KEYBASE SALTPACK SIGNED MESSAGE.

Thanks again for your prompt help. I love Keybase - I just clearly need to learn more about it!

If there's no time period when KBFS is running on the old device after the new device is added, but before you revoke the old device, you will lose your data.
We probably need to make this clearer in the revoke process, if you are at risk for losing data.

This sounds good - IMHO you should enforce the existence of a paperkey for which KBFS has been keyed - it should not be revokable without first creating and keying against a new one, regardless of active devices. Devices could be lost/stolen/wiped/killed at any time; Keybase can't anticipate that.

Cheers.

[strib]

@OJFord: done. Can you see if that works? (You might need to restart KBFS, depending on the state of your local client.)

Also, can you confirm that you can still write to your public folder?

[OJFord]

Sorted, cheers!

Also, can you confirm that you can still write to your public folder?

Looks good!

[strib]

Sweet. Very sorry for the data loss -- you shouldn't have to learn more about how Keybase works to prevent data loss, it should just magically work. We'll work on making that clear in the revoke workflow. Thanks for the report!

[malgorithms]

@oconnor663 worked on that feature last. I think there is backend support
for it that electron might not have plumbed through. But maybe we need CLI
support too.

There are design screens for this (for some reason I thought already on the electron side too, but maybe they'll be done soon), but yeah, the CLI should of course give the exact same warning. If you try to revoke a device, and there are any KBFS folders that (1) the device getting revoked can read, and (2) your current device cannot read, it's supposed to give you big-ass warnings that you could suffer data loss. This warning has to exist even if there are other devices still left that can read it, since those might be lost to the you, too, and up for revocation next.

Related to this, we need to avoid the problem in the first place, since the device you're revoking might actually already be lost to you...which unfortunately means that if rekeys are going to take more than a few seconds (I had that one take 6 minutes recently, and that was on a desktop -- I assume mobile on cellular will be worse), it seems we need to feed this back into the provisioning workflow and show someone some kind of progress bar or something, and ask they don't close their app until "provisioning" (which, from their perspective, should include rekeying) is done. Otherwise, I think this will keep happening to us.

TLDR: A warning just at the revocation isn't enough, since nature has a way of revoking devices...

I ended up in a swimming pool last weekend with both my phone and a water-soluble paper key :-|

[maxtaco]

At the very least keybase/private/you ought to be rekeyed within a second.
The others are slightly less problematic because the other readers can also
rekey.

On Thursday, September 15, 2016, Chris Coyne [email protected]
wrote:

@oconnor663 https://github.com/oconnor663 worked on that feature last.
I think there is backend support
for it that electron might not have plumbed through. But maybe we need CLI
support too.

There are design screens for this (for some reason I thought already on
the electron side too, but maybe they'll be done soon), but yeah, the CLI
should of course give the exact same warning. If you try to revoke a
device, and there are any KBFS folders that (1) the device getting revoked
can read, and (2) your current device cannot read, it's supposed to give
you big-ass warnings that you could suffer data loss. This warning has to
exist even if there are other devices still left that can read it, since
those might be lost to the you, too, and up for revocation next.

Related to this, we need to avoid the problem in the first place, since
the device you're revoking might actually already be lost to you...which
unfortunately means that if rekeys are going to take more than a few
seconds (I had that one take 6 minutes recently, and that was on a desktop
-- I assume mobile on cellular will be worse), it seems we need to feed
this back into the provisioning workflow and show someone some kind of
progress bar or something, and ask they don't close their app until
"provisioning" (which, from their perspective, should include rekeying) is
done. Otherwise, I think this will keep happening to us.

TLDR: A warning just at the revocation isn't enough, since nature has a
way of revoking devices...

I ended up in a swimming pool last weekend with both my phone and a
water-soluble paper key :-|

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/4279#issuecomment-247330667,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA05_wCyrF6Z996YQ-pNHitFoe6cb2_oks5qqUrFgaJpZM4J9OIQ
.

[maxtaco]

And btw the nature of Ollie's problem is that he was running a version of
keybase that didn't do rekeying.

On Thursday, September 15, 2016, Chris Coyne [email protected]
wrote:

@oconnor663 https://github.com/oconnor663 worked on that feature last.
I think there is backend support
for it that electron might not have plumbed through. But maybe we need CLI
support too.

There are design screens for this (for some reason I thought already on
the electron side too, but maybe they'll be done soon), but yeah, the CLI
should of course give the exact same warning. If you try to revoke a
device, and there are any KBFS folders that (1) the device getting revoked
can read, and (2) your current device cannot read, it's supposed to give
you big-ass warnings that you could suffer data loss. This warning has to
exist even if there are other devices still left that can read it, since
those might be lost to the you, too, and up for revocation next.

Related to this, we need to avoid the problem in the first place, since
the device you're revoking might actually already be lost to you...which
unfortunately means that if rekeys are going to take more than a few
seconds (I had that one take 6 minutes recently, and that was on a desktop
-- I assume mobile on cellular will be worse), it seems we need to feed
this back into the provisioning workflow and show someone some kind of
progress bar or something, and ask they don't close their app until
"provisioning" (which, from their perspective, should include rekeying) is
done. Otherwise, I think this will keep happening to us.

TLDR: A warning just at the revocation isn't enough, since nature has a
way of revoking devices...

I ended up in a swimming pool last weekend with both my phone and a
water-soluble paper key :-|

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/4279#issuecomment-247330667,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA05_wCyrF6Z996YQ-pNHitFoe6cb2_oks5qqUrFgaJpZM4J9OIQ
.

[patrickxb]

I like this idea of provisioning proactively doing a rekey and waiting until it is complete...

[oconnor663]

@malgorithms you're right, we created the backend bits for this, and I think Electron shows the warning now, but we haven't plumbed the warning through to the CLI. I'll file a task now.

[maxtaco]

I made a ticket this morning for the CLI work

On Thursday, September 15, 2016, oconnor663 [email protected]
wrote:

@malgorithms https://github.com/malgorithms you're right, we created
the backend bits for this, and I think Electron shows the warning now, but
we haven't plumbed the warning through to the CLI. I'll file a task now.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/keybase/client/issues/4279#issuecomment-247381692,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA05_yK6TAZo5rM6dbVUGs3C_X3tttmvks5qqXQ0gaJpZM4J9OIQ
.

[b4rton]

I changed phones and upgraded my Mac to High Sierra. The phone and the Mac now ask me to rekey (why should the Mac OS upgrade do this?) but I apparently have no validly keyed device.

1. Respectfully, you make it hard to figure out what to do about that. I shouldn't have to come to Github to figure it out. You might also make more prominent on keybase.io that help is to be found here, not your own site.

2. The app tells me (on Mac and iOS) that I need to rekey and that unless I open one of the (inaccessible) devices I'm "at risk of losing data forever." (No, I don't have a paperkey but I will next time, promise.) I don't save content or chats so I don't care about losing data forever. But the app doesn't let me say, OK, I understand, please rekey anyway and abandon the data. It should.

3. This thread tells me I could go to the cog icon on the web site and reset the whole account. (That should also be possible from the app.) I'd rather not take the trouble to reverify my Twitter, Github, etc. I've already proved my identity once. I'm not changing GPG keys. All I want to do is make Keybase function again.

4. Based on this thread, I have the impression that the good folks at Keybase can "manually reset" my private folder without starting all over. I should have that option on your app, should I not? And shouldn't you say in the dialog from the cog that this option exists before letting someone nuke their whole account?

I do appreciate the support here. If you can do a manual reset for me, without making me reverify my external accounts, please do:

BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkWf30BZ HYy5gxbY94g8sUF DAnanpXtmi0wlFh mJCQ4OE0fGRl9gS JnwHfA2uZNIClyO ENZnenmb1pTjupK 3kIQCXkn3GX2crf RB8FgX5DhfH98j4 wKexFTnpe8lHwOS R3vp4ACWqKd5SCW GCATGedVnkMMhra 5u77UteuAowmyde MGQX9z5mHKy0Lqs ENZjPNylvwNI9QZ gqIOVnehkoGb9fz yM6OFRKQHXA3HRB D0rRMYKMgLpVxNO v2BOtl2KTPtlyWj O1y46f05pFYSTMg 97efMdlXk6TJ2Wb FaAfhEMPZqrP5oB VntxBRYvHLRpeC6 OeZyqcr42hSTRz8 nkAqwEwqLYxvunc erSCvuyM2ms. END KEYBASE SALTPACK SIGNED MESSAGE.

Cheers,
Bart

[strib]

@b4rton: your private folder is currently keyed for your devices iphone and Mac-BG. Neither of these devices have been revoked, which means as far as keybase is concerned, you can use them to rekey your folder. If you have lost these devices permanently, you should revoke them, and then Keybase would stop bugging you about rekeying.

Though it's not something we want to encourage, it might be a nice last-ditch feature to let users reset their own folders. However, we're a small team and it's a rare situation, so we haven't been able to prioritize it yet.

I can reset the folder if you still want me to, but in the above signed message, you didn't replace "" with the current date and time, and we require that to be signed over so someone can't replay the message later. So please post an updated message if you want that.

Also, in the future please open new issues for resetting a folder, rather than commenting on closed issues. Thanks!

[maxtaco]

This feels like a bug, since the private folder is supposed to be rekeyed first. @b4rton can you keybase log send?

[strib]

Specifically the bug would have been when you were provisioning BG-iPhoneX with your Mac-BG device. So the relevant log send would have to be from Mac-BG, which is apparently lost. But if you still somehow have it, please keybase log send from Mac-BG.

[b4rton]

Hi guys, thanks for the replies. You're right @strib, I don't have the Mac-BG device available, so no logs.

I revoked iphone and Mac-BG, and they no longer show as devices, but a test conversation I had with myself (bartongellman) still tells me I have to rekey, and I can't start a new conversation with myself. I'm likewise unable to delete that conversation.

Next time I'll start a new thread. Since we're here:

BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkWf30BZ HYy5gxbY94g8sUF DAnanpXtmi0wlFh mJCQ4OE0fH5gj04 zOB09AFq9ZPXM9i NDnllSGHOtrLlXI d8FvRqBIo8A6HuZ PTwnsjw35almY70 GUmWFlAaLayKLzO 2S9AvSMXTJuxKDU AHZfmc6kXThwPmb V5KVnlBEwrDvCFz 2CCi9SjsmrfXwI8 oetDAO2VbByG12h 9H0doHfD2DHfxvl 28AS7dBWLTQTUAE SDVSmbWfBwEksAP 1mMwCIjOcuP2Bh8 yxTwTdvH7L28Emb eQLnMnH7F8YJP88 qSTprebsGHEGQaN 1mqY1PhBp705jg1 HHsgrA4ehGufAYl vc7bhT3kivD6XVb WrrPl0. END KEYBASE SALTPACK SIGNED MESSAGE.

[strib]

I reset the folder. Please check it out. (Might require a Keybase restart.)

[strib]

Actually @b4rton I just noticed another problem with your signed message, it says you want to reset ojford's folder. I reset the correct folder, but I should have checked the message more carefully first. As a favor, can you please post another message about the correct folder, for our records?

[b4rton]

Ug, that was dumb.

Here you go. Everything seems to be working now.

BEGIN KEYBASE SALTPACK SIGNED MESSAGE. kXR7VktZdyH7rvq v5weRa0zkJC2tG6 HfPdaP79hsv8F8l QR5pq6xxyaC8Syy DkbeY0rNmz9Y2Ie tx7RcnwtYScabWg Lr6TFQrUzLOF7YP 8QMV2Qy7rI2TwbJ u9spYgC4ZHrFlyw N4PyYGUfbTtYp3H KZUjh5t0Dk34LpE TefOtWiIoBGMa2M V4srVuKYK9VhZak huii0qmWEYBnO6Q ZuGAGO2VbByG12h 9H0doHfD2DHfxvl 28AS7dBWLTQTUAE SDVSmbWfBwEksAP 1mMwCIjHrYxVDR7 WULDGmeAnzjdAzX lRqlz8gtiWh3UON ypymPXnAndYQh9D YTX02cRlqXGgxVQ CBg6iQnqUZilGct BZYpUTTmKa6J0pj r6jZe39B4TNv7bS . END KEYBASE SALTPACK SIGNED MESSAGE.

[OJFord]

Ha! Nice try @b4rton... 😉 😆

[strib]

Thanks!

[b4rton]

Um, sorry @OJFord. Stupid copy/paste without reading.... Hope I didn't scramble your nuclear codes or something.