Keybase reset leaves the private key in place.

[leedavis81]

When performing a keybase login on a user with a hosted private key that key is downloaded and registered to the user's gpg keyring.

I believe a keybase reset (which removes any established session, local cache and deregisters the user from the client) should also remove the private key from the gpg keyring (if it put it there).

If would be fair for any user of the keybase client to assume that a keybase logout and reset would destroy any residual information about their usage. However this isn't the case.

Leaving these keys in place would then allow anyone that gained / was granted access to the users machine (as that user thought all key information / sessions were destroyed) to then be able to create an encrypted message for another keybase user

gpg --import {keybase users public key}

echo "message" | gpg --output message.txt --encrypt -r {private key name} --recipient {user}@keybase.io

I understand a user that only uses a local private key (not uploaded to keybase) wouldn't want their private key removed from their keyring. So it could be left in tact in this instance.

[MattSurabian]

This seems like an overstep. The user may have encrypted things for themselves on their local machine and killing that key from their GPG Keyring will lock them out of those files forever.

[leedavis81]

It will, but I believe all clients (including anything else built on top of the keybase API) should clean up after themselves.

I think it would make more sense to have an (x client) application keyring than was removed on cleanup. Then anyone maintaining their private key offline could run something like a keybase pull and provide a path to their private key to be added into the application space keyring.

Then a reset command would clean up entirely.

You can uses gpg's --homedir command to point to another keyring space. The cli tool can then use this space instead of altering / using the users main keyring.

[MattSurabian]

This still misses the point that a user may be using keybase to encrypt things for themselves. Just because a user wants to reset their keybase account does not mean they should suddenly loose access to everything their old key touched. As is the wording on reset makes it seem as if the users key is going to be revoked, and that's bad enough heh.

In general I agree that programs should clean up after themselves, but there isn't any way of knowing how an individual user is leveraging keybase.

Further, keys expire, a user might reset their keybase account to update their key and intend to deal with migrating their personal stash of encrypted files at a later date before then destroying or archiving their current key.

No matter how you slice it, no amount of "cleanup" is worth a user being locked out of personal files forever.

[leedavis81]

I think you misunderstood my point.

If your private keys we're imported into an application space (keyring) then they'd still exist at wherever they were imported from.

If keybase pull (from server) or keybase pull (from local) imported into an application space keyring. Then it'd be the applications job to clean up that space. Anywhere they existed previously (for a local import) is the users domain.

I fail to see the risk of locking users out with this setup.

[MattSurabian]

I see what you're saying now, I did misunderstand your point a bit.

Perhaps unsurprisingly, I still prefer the way keybase is hooked into my GPG Keyring. I have that backed up, and I'm using keys that I've always had in GPG. When I open GPG Tools I see all the keybase users that I'm tracking and for me, the direct pairing with GPG was always a big attraction.

I don't think that would be happening if keybase were to use its own home directory, would it?

Curious to see what others think about this though.