search

qri-io / rfcs

Request For Comments (RFCs) documenting changes to Qri
MIT License
12 stars 6 forks source link

RFC: externalize private key #52

Closed b5 closed 4 years ago

b5 commented 4 years ago

I think we should land this one before the configuration RFC. It informs design changes to our config, and takes some pressure off that RFC to explain how we're going to address https://github.com/qri-io/qri/issues/1306

ramfox commented 4 years ago

Of all the comments and inputs so far, my biggest battle is with the location of the key itself.

  • Don't like the obscure location (even if it makes kind of sense) - from a user perspective it's "hard" to find
  • .ssh feels conceptually right, but realising this is not a given on many machines scares me completely away
  • technically the .qri folder makes sense namewise however we've put so much into it that we came to the current problem in the first place
  • Is a file in the home folder sensible like a .qri_profile (but I don't like such an important thing as a key just hanging there)

Idk, very conflicted on this.

@Arqu Does it help to think about the idea that this isn't the primary location for the key? The primary location is the os keychain which isn't obscure. The backup is just for situations where the user has removed the identity from the keychain, and can be used by qri to restore the expected behavior & would be documented. I'm not sure why the user would ever need to explicitly know where the key is stored (besides the keychain), unless they are in some super advanced use case in which case we should be documenting this all anyway and they can find it that way.

Arqu commented 4 years ago

Of all the comments and inputs so far, my biggest battle is with the location of the key itself.

  • Don't like the obscure location (even if it makes kind of sense) - from a user perspective it's "hard" to find
  • .ssh feels conceptually right, but realising this is not a given on many machines scares me completely away
  • technically the .qri folder makes sense namewise however we've put so much into it that we came to the current problem in the first place
  • Is a file in the home folder sensible like a .qri_profile (but I don't like such an important thing as a key just hanging there)

Idk, very conflicted on this.

@Arqu Does it help to think about the idea that this isn't the primary location for the key? The primary location is the os keychain which isn't obscure. The backup is just for situations where the user has removed the identity from the keychain, and can be used by qri to restore the expected behavior & would be documented. I'm not sure why the user would ever need to explicitly know where the key is stored (besides the keychain), unless they are in some super advanced use case in which case we should be documenting this all anyway and they can find it that way.

Keychain as a backup source for the "main" key location sounds good to me. Then we can keep the original in .qri and have the fallback on keystore. With that both feel like they are in their proper place.

b5 commented 4 years ago

I'm not sure why the user would ever need to explicitly know where the key is stored

When they want to completely remove Qri. Having software not go away totally when being removed is always scary *cough* zoom *cough*.

After hearing out both sides, I feel like we should keep this RFC as-written: only place keys in .qri and the OS keychain, and warn the user when we can't write to the keychain.

No matter what we do, we're going to land these changes in phases, starting with work to backup keys to the OS keychain, then adding a warning when keys aren't backed up. At that point we'll be in a situation where keys are stored in both .qri and the keychain, and can use that moment to evaluate if we need more work to externalize keys from the .qri folder.

My three main concerns with an extra folder:

Let's get the OS Keychain backup to work well, and a good warning in place. We can figure out if a third location is necessary once that work is done

b5 commented 4 years ago

Ratified. Thanks all!