keybase / keybase/keybase-issues
Please natively support hassle-free device migrations
- Dominant language
- No language data
- Stars
- 899
- Forks
- 40
- PR merge metrics
- No merged PRs in 30d
Description
(Follow-up to [this](https://github.com/keybase/keybase-issues/issues/2990#issuecomment-532077575).)
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](https://keybase.io/hexstream/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](https://keybase.io/hexstream/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.
Contributor guide
No contributing guide indexed for this repository
Research direction
The proposed workflow uses ~/.config/keybase/config.json, ~/.config/keybase/secretkeys.hexstream.mpack, and run_keybase -k. Start by reviewing how the existing device identity is stored and how run_keybase handles shutdown and startup. Done would mean an officially supported migration workflow, including documented backup and restore commands with appropriate security warnings.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- debian
- Domain
- cli, documentation, operating-systems, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 20/100