search

keybase / keybase-issues

A single repo for managing publicly recognized issues with the keybase client, installer, and website.
899 stars 37 forks source link

Please natively support hassle-free device migrations #3565

Open Hexstream opened 5 years ago

Hexstream commented 5 years ago

(Follow-up to this.)

I have just upgraded my debian version, effectively a "reinstall" on the same physical and logical machine. I destroyed the old debian partition and installed the new one in the same place.

Currently, the only officially supported way of doing this would have been to provision the new debian install as a completely new device with a new name (keybase does not allow device name reuse) and revoke the old device (the previous debian install). I just thought that doing it this way would be fairly ridiculous in my case.

Keybase's main selling points are security and convenience, and there's nothing convenient about having to use a new name for the same physical and logical device just because of a routine OS upgrade, and spamming the public graph with meaningless device provisionings and revocations arguably reduces security. I think it would be best if device revocations remained a rare occurrence, and I just don't think the world needs to know every time someone upgrades their OS or otherwise needs to perform a reinstall or other simple migration.

So, to avoid all this nonsense, the way I did my upgrade was very simple:

  1. Save a copy of ~/.config/keybase/config.json and ~/.config/keybase/secretkeys.hexstream.mpack (let's call this "keybase device identity").
  2. Upgrade OS (fresh install) and install keybase normally.
  3. Invoke run_keybase -k to kill all keybase processes, reinstall keybase device identity, restart keybase with run_keybase.
  4. Preferably, destroy all other copies of the keybase device identity.

This has been a wonderful experience, and I'm really happy I could keep the same device name and keep a clean public graph, especially in my case where I have as devices only 1 machine, 2 paper keys and 0 revocations.

I understand that you want to avoid users insecurely sending their device keys all over the place, but I still think you should officially support this "device transition" workflow for simple cases such as when the same physical and logical machine is being upgraded in-place. This should be at least minimally documented, and please consider adding a few commands to easily backup and restore keybase device identities. These new commands could appropriately warn the user about best practices.

lord-aerion commented 4 years ago

This is a must for those of us who try out several custom Android ROMs in order to find one that works best.

But even if you're not a ROM hopper, performing a factory reset is a common solution for a phone that has slowed down over time.

Definitely a must. The potential risks can be pointed out in documentation, but the choice should be left to the user.

nuke-web3 commented 4 years ago

+1 for making this easier and in the main docs as a how-to