Guidance on dotfiles

[jasonkarns]

Tangentially related to https://github.com/keybase/keybase-issues/issues/277.

Many CLI users are ardent dotfiles users (versioning and posting of $HOME directories and dotfiles repos to github). Could a quick blurb be posted somewhere providing some guidance on which, if any, of the .keybase and .keybase-installer files ought to be backed up, which could be public, which must remain private, and which are safe to ignore?

[xero]

personally, i keep keys of any kind out of my dotfiles.

[jasonkarns]

@xero agreed, but there are more than key files under the .keybase and .keybase-installer directories. some of which are obviously configuration, but it's not clear what, if any, of the configuration is safe to publicize

[maxtaco]

As it stands now, the dotfiles we have are:

   .keybase/
        |
        + ---- config.json
        |
        + ---- session.json
        |
        + ---- keybase.idb/
        |
        + ---- tmp_keyrings/

All but session.json contain only public data. Session.json contains your session key and your CSRF token for making REST requests. If your worst enemy got that file, he/she could deface your keybase profile and delete keys and proofs, but they couldn't decrypt your secret data or sign as you or get access to your secret key.

config.json usually has only your keybase username, userID and a salt, but you can configure it to hold options via keybase config foo bar, which would set config var foo=bar. This is probably the only thing work backing up.

Your keys are all stored in the GnuPG keychain (under ~/.gnupg), so they won't be in ~/.keybase at all

The keybase.idb database is a cache of the relevant signed statements fetched from the server. We keep them cached to (1) save bandwidth; and (2) catch the server in a rollback attack.

tmp_keyrings ought to be empty, but if the CLI crashes midstream, you can wind up with some quarantined keys in there. You should feel comfortable nuking that directory at any time.

[maxtaco]

Oh, and ~/.keybase-installer keeps keybase's code-signing public key. I didn't want to keep it in ~/.gnupg for fear that a bad guy could fool you into downloading a public key that would be mistaken for keybase's and trick you into installing/downloading a malicious client.

[jasonkarns]

@maxtaco thanks for the info! sounds like the files i'd want to back up are:

.keybase/config.json and .keybase-installer/keyring/pubring.gpg/.keybase-installer/keyring/trustdb.gpg

versioning the keybase installer key should make any tampering noticeable.

Should the config.json salt be versioned? I assume the salt would be machine-specific? Or is unique per keybase account? (I ask because versioning my dotfiles is mainly about unifying various machines, and less about backup.)

[maxtaco]

The keys are versioned so that if you ran the installer with key v1, you can download a new installer with key v4 and check that the new key is signed by the old.

The key versions are kept in the PGP comment fields in that keyring.

I tested all of that stuff before launch. I hope that key upgrading will work when we need it :) On Aug 6, 2014 2:23 PM, "Jason Karns" notifications@github.com wrote:

@maxtaco https://github.com/maxtaco thanks for the info! sounds like the files i'd want to back up are:

.keybase/config.json and .keybase-installer/keyring/pubring.gpg/ .keybase-installer/keyring/trustdb.gpg

versioning the keybase installer key should make any tampering noticeable.

Should the config.json salt be versioned? I assume the salt would be machine-specific? Or is unique per keybase account? (I ask because versioning my dotfiles is mainly about unifying various machines, and less about backup.)

— Reply to this email directly or view it on GitHub https://github.com/keybase/keybase-issues/issues/908#issuecomment-51375574 .

[maxtaco]

The salt is per keybase account. Every user gets their own random salt. To prevent against rainbow table attacks if our DB is compromised.

The salt BTW is public since your client can fetch it before you login. On Aug 6, 2014 2:23 PM, "Jason Karns" notifications@github.com wrote:

@maxtaco https://github.com/maxtaco thanks for the info! sounds like the files i'd want to back up are:

.keybase/config.json and .keybase-installer/keyring/pubring.gpg/ .keybase-installer/keyring/trustdb.gpg

versioning the keybase installer key should make any tampering noticeable.

Should the config.json salt be versioned? I assume the salt would be machine-specific? Or is unique per keybase account? (I ask because versioning my dotfiles is mainly about unifying various machines, and less about backup.)

— Reply to this email directly or view it on GitHub https://github.com/keybase/keybase-issues/issues/908#issuecomment-51375574 .

[simonvanderveldt]

Is it still OK to share ~/.config/keybase/config.json between multiple machines? I see a device key in the users block now, which seems to suggest it's machine specific