Skip to content
This repository has been archived by the owner on Jun 19, 2023. It is now read-only.

Add method to import keys into keychain #64

Closed
wants to merge 1 commit into from
Closed

Conversation

rendaw
Copy link

@rendaw rendaw commented Jul 15, 2020

Per ipfs/kubo#4240 I thought I'd move toward the first steps here.

Exported key storage format

  • This can be an opaque format. The goal is backing up one's identity and using it on multiple workstations/devices, neither of which usecases need to know the internal format.
  • PrivKey already has marshal/unmarshal. I don't know if these include a version number/are future proof/are frozen but PrivKey is a good target since everything else can be derived from it.

Import
Since the serialized format is opaque Import takes a blob.

Export
Users might want to install ipfs, generate a key, and import it on another (remote?) machine without setting up ipfs locally. That said, I think there are two options here:

  1. Add additional parameters to Generate (flag to generate only without storing), plus the private key as a blob would need to be included in Key or a new return type defined. I'm not sure what backward compatibility guarantees are here... I've seen some other libraries do things like Generate2 Generate3 to avoid breaking the interface.
  2. Alternatively it might make sense to ignore Generate and crypto or something can provide a standalone function for creating keys from KeyGenerateOption, which can then be added with Import. In that case only Import is needed here I think.

@welcome
Copy link

welcome bot commented Jul 15, 2020

Thank you for submitting this PR!
A maintainer will be here shortly to review it.
We are super grateful, but we are also overloaded! Help us by making sure that:

  • The context for this PR is clear, with relevant discussion, decisions
    and stakeholders linked/mentioned.

  • Your contribution itself is clear (code comments, self-review for the
    rest) and in its best form. Follow the code contribution
    guidelines

    if they apply.

Getting other community members to do a review would be great help too on complex PRs (you can ask in the chats/forums). If you are unsure about something, just leave us a comment.
Next steps:

  • A maintainer will triage and assign priority to this PR, commenting on
    any missing things and potentially assigning a reviewer for high
    priority items.

  • The PR gets reviews, discussed and approvals as needed.

  • The PR is merged by maintainers when it has been approved and comments addressed.

We currently aim to provide initial feedback/triaging within two business days. Please keep an eye on any labelling actions, as these will indicate priorities and status of your contribution.
We are very grateful for your contribution!

@rendaw
Copy link
Author

rendaw commented Jul 15, 2020

Two other thoughts.

  1. If the format is opaque, maybe this interface should also include ascii encoding and return a string instead.
  2. If the marshalled output of p2p crypto keys isn't stable, maybe going to std crypto and using those marshal functions would be an option.

@rendaw
Copy link
Author

rendaw commented Jul 16, 2020

Closing per discussion in issue ticket.

@rendaw rendaw closed this Jul 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant