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

Evaluate refactoring or possible rewrite of Keyring #14473

Closed
ainhoa-a opened this issue Jan 4, 2023 · 8 comments
Closed

Evaluate refactoring or possible rewrite of Keyring #14473

ainhoa-a opened this issue Jan 4, 2023 · 8 comments
Assignees
Labels
C:Keys Keybase, KMS and HSMs

Comments

@ainhoa-a
Copy link

ainhoa-a commented Jan 4, 2023

A short review and evaluation of a possible rewrite of Keyring is proposed.

@ainhoa-a ainhoa-a added the C:Keys Keybase, KMS and HSMs label Jan 4, 2023
@tac0turtle
Copy link
Member

tac0turtle commented Jan 4, 2023

would love to have a chat about this. there was this work https://github.com/cosmos/keystone that stopped last year. The concept is really good and could be extendable to other forms of singing without supporting it in the sdk

@JulianToledano
Copy link
Contributor

@tac0turtle that looks like a really good approach.
The main goal of this refactor should be the possibility of use different signing algos as is something the community is requesting.

We should focus on:

  • Generate a common interface for implementing different algos
  • Makes those algos pluginable so there is no need to rebuild the sdk for custom algos

It should be as simple as possible to be easy to use and tweak

@tac0turtle
Copy link
Member

oh okay. Keystone is a different layer. You are talking about Algos and im talking about signing methods. We do already support injecting different algos, but maybe it could use a refresh

@JulianToledano
Copy link
Contributor

oh my bad there! but if I’m not wrong the injection of the algos is not dynamic, right? someone should fulfil the SignatureAlgo interface and add it to SupportedAlgos. That would require to do before compiling.

@tac0turtle
Copy link
Member

yes build time addition, runtime injection isn't really needed here

@JulianToledano
Copy link
Contributor

👋 , @tac0turtle
We took a look at keystone and the idea is really great, although the code is not currently working. The idea would be to start working and maintain it so in the near future we can replace the current keyring and remove the dependency with 99designs/keyring which is not really active right now. One of the main goals will be to define an interface so new backends are easy to develop and integrate.

However there are small improvements that can be easily achieved.

  1. Use cosmossdk.io/errors instead of github.com/cosmos/cosmos-sdk/types/errors and github.com/pkg/errors
  2. Define errors as variables instead. There are some errors that are created at the return level.
  3. Some functions as ImportPubKey(uid string, armor string) error can be change to ImportPubKey(uid, armor string) error to be more compliant with the code style.

@tac0turtle
Copy link
Member

this sounds good to me, would be amazing to have keystone working and allowing other to extend backend types

@ainhoa-a
Copy link
Author

ainhoa-a commented Feb 2, 2023

Hi @tac0turtle thanks for the feedback! we'll get started with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C:Keys Keybase, KMS and HSMs
Projects
None yet
Development

No branches or pull requests

4 participants