Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove identity from config file. place private, public keys in id, id.pub files #744

Closed
3 tasks done
btc opened this issue Feb 5, 2015 · 3 comments
Closed
3 tasks done
Labels
kind/enhancement A net-new feature or improvement to an existing feature topic/repo Topic repo

Comments

@btc
Copy link
Contributor

btc commented Feb 5, 2015

connected to #783

WIP: https://github.com/jbenet/go-ipfs/tree/feat/identity

  • create FSRepo.Identity component
  • write files to id, id.pub files
  • read identity into memory (*Config)
@btc btc added the kind/enhancement A net-new feature or improvement to an existing feature label Feb 5, 2015
@btc
Copy link
Contributor Author

btc commented Mar 3, 2015

@jbenet @whyrusleeping @cryptix

code

On branch https://github.com/jbenet/go-ipfs/tree/feat/identity, ipfs learns to read and write the Identity from id and id.pub files in the IPFS_PATH.

compatibility

Presently, It is not backwards compatible with old configs/repos.

Old configs must be updated:

  1. read Identity from config
  2. write Identity to id, id.pub
  3. finally, overwrite config file with Identity erased

From here forward, this is referred to as the update procedure.

proposal

I see a couple ways to provide backward compatibility.

a) Provide a command/script/tool allowing user to manually perform the update procedure.

pros: puts user in control
cons: inconvenient. commands will fail

b) During normal operation, if old config is detected, let ipfs silently perform update procedure.

pros: least painful for the user
cons: complexity is shifted to code; users might find this behavior surprising

Thoughts?

@jbenet
Copy link
Member

jbenet commented Mar 3, 2015

I like the ssh keys approach. But we need to have sets of keys, not just one. AFAIK only one key per file in ssh, so we'd need a way to account for them.

Then again, the widest system in use is pgp/gpg keyrings (.pubring.gpg and .secring.gpg) which many people in infrastructure world are used to for deployments / signing + validating binaries, etc:

I wonder if -- going the ssh route -- we can interface with ssh-agent too.


On making backwards incompatible changes to repos, please see:

We write the upgrade/downgrade tool, and run it automatically as part of the upgrade procedure (which can be run at the beginning when launching new versions for the first time), but user can step in manually and run the tools to fix things if needed.


thanks @briantigerchow!

@jbenet jbenet added the topic/repo Topic repo label Mar 28, 2015
@jbenet jbenet modified the milestone: Flat Repo and More Mar 29, 2015
@whyrusleeping
Copy link
Member

keys will soon be stored in the blockstore, once it can be 'private'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature topic/repo Topic repo
Projects
None yet
Development

No branches or pull requests

3 participants