keybase / keybase/keybase-issues

Please natively support hassle-free device migrations

Open
#3,565 2 comments 6 reactions 0 assignees View on GitHub
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.