search

sandstorm-io / sandstorm

Sandstorm is a self-hostable web productivity suite. It's implemented as a security-hardened web app package manager.
https://sandstorm.io
Other
6.76k stars 706 forks source link

spk: store keyring at ~/.sandstorm/sandstorm-keyring like vagrant-spk #3345

Open zenhack opened 4 years ago

zenhack commented 4 years ago

Right now spk and vagrant-spk store their keyrings in two different places:

The reason for this is historical; spk came first, but per comments in vagrant-spk's source, it's not possible to share a single file with a guest VM, and the authors (sensibly) didn't want to share the user's entire home directory with the VM.

One thing that's been talked about here and there is that it would be nice to reduce the discrepancies between the two tools, to make switching between them easier. There's not a strong reason for spk to not do what vagrant-spk is doing, so I prepose we move the default keyring location.

There is a question regarding what to do with existing keyrings. Some possibilities:

  1. Try to migrate old keyrings at ~/.sandstorm-keyring to the new location.
  2. Leave existing keyrings where they are, but create new keys in the new location, and when searching for a key, unless the keyring was specified explicitly with -k, search the old location if the key is not found in the new one.

(2) seems like it would be easier to get right.

Thoughts?

kpreid commented 4 years ago

As a person who occasionally sorts through and migrates home directory content: please don't leave me with silently superseded files. (That is, option 1 unless there's an even better one.)

ocdtrekkie commented 4 years ago

I'd be very hesitant to migrate people's keyrings, because they're both very sensitive and very valuable, and they may or may not have practices for backing them up.

I would go so far as to suggest that on a given system, if an existing keyring exists in one of the two places we recognize it, we should continue to use that keyring. And if there is no keyring detected, defer to the vagrant-spk location for new keyrings.

zenhack commented 4 years ago

Quoting Jacob Weisz (2020-05-22 23:29:31)

I would go so far as to suggest that on a given system, if an existing keyring exists in one of the two places we recognize it, we should continue to use that keyring. And if there is no keyring detected, defer to the vagrant-spk location for new keyrings.

My system has a keyring in both locations. Ideally any solution we came up with would not result in some of those apps not being able to find their key, hence my fallback search suggestion.

I appreciate the desire not to clutter one's home directory more than necessary. But I'd also prefer not to have to write code that deletes private keys if I can avoid it...

ocdtrekkie commented 4 years ago

Yeah, if keyrings are in both locations we should look for both, and new keys should go to the newer location. My thought is that if someone only has a keyring in the legacy location, we should continue to put new keys there.

griff commented 3 years ago

The way NixOS deals with the similar issue of moved configuration options works pretty well: When an option changes name they keep supporting the old name but whenever rebuilding the configuration it detects that an old name is used and prints a big red "Warning: you are using which has been renamed to please update your configuration!"

In a similar way spk could look for key in both old keyring and new keyring and if found in the old simple use that key but also print a big red warning about you the user needing to migrate the key. You could even provide a migrate-keyring spk subcommand to make it super simple to migrate. That way no moving of keys is ever done behind the users back, there is only one official location for the keyring (and a legacy location), we are notifying users of the change they need to make in a way that is slightly annoying and possible providing a command to make the migration easy.

zenhack commented 3 years ago

I think that's a good solution.