-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
feat!: key rename cli command #9601
Conversation
Codecov Report
@@ Coverage Diff @@
## master #9601 +/- ##
===========================================
+ Coverage 35.48% 63.42% +27.94%
===========================================
Files 332 574 +242
Lines 32620 37648 +5028
===========================================
+ Hits 11575 23880 +12305
+ Misses 19819 11900 -7919
- Partials 1226 1868 +642
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left some nits and also could you resolve the conflicts ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Manually tested. Seems to be working without issues. A couple comments.
@@ -1153,6 +1153,52 @@ func TestBackendConfigConstructors(t *testing.T) { | |||
require.Equal(t, "keyring-test", backend.PassPrefix) | |||
} | |||
|
|||
func TestRenameKey(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For each test, should we check more than just an error? Should we also check whether each key does or does not exist within the keyring after renaming?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also check whether each key does or does not exist within the keyring after renaming?
this is already checked on L1175 and L1182-L1183
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Within this test, rename is called three times at the end without checking the specific error thrown or what keys exist after each failed attempt. I was thinking the extra checks would be added to the failed attempts. At the least, I think we should check to make sure we are receiving the expected error and not just any error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
refactored the tests. should be a bit more concise. let me know if its missing anything please!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I like the direction with adding test cases. I'm not sure if it's necessary given that the only parameter for each test case is the run
function and there is no overlap with the key names you are using so creating a new keyring for each test case might not be necessary but I also think it's ok to leave it as is.
Co-authored-by: likhita-809 <[email protected]>
crypto/keyring/keyring.go
Outdated
return errors.New(fmt.Sprintf("rename failed: %s already exists in the keyring", newName)) | ||
} | ||
|
||
passPhrase := "temp" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: this should be a private const
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup that makes much more sense - moved it to the other private const vars
Co-authored-by: Aleksandr Bezobchuk <[email protected]>
crypto/keyring/keyring.go
Outdated
err = ks.Delete(oldName) | ||
if err != nil { | ||
return err | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be called after ImportPrivKey
? What happens if ImportPrivKey
fails? The account is deleted and no new account is created.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so import will actually fail if you delete last, cause import doesn't allow same pubkeys. some solutions i can think of:
-
dump the key information in a recovery file
-
update the ImportPrivKey method to allow keys with same pubkeys, but different keyring names
thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the name
is the primary index, I think it's OK to go with (2).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
alright, changed the write behavior to allow duplicate keys, as long as the names are different.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tACK. No necessary changes but I left a few comments.
@@ -1153,6 +1153,52 @@ func TestBackendConfigConstructors(t *testing.T) { | |||
require.Equal(t, "keyring-test", backend.PassPrefix) | |||
} | |||
|
|||
func TestRenameKey(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! I like the direction with adding test cases. I'm not sure if it's necessary given that the only parameter for each test case is the run
function and there is no overlap with the key names you are using so creating a new keyring for each test case might not be necessary but I also think it's ok to leave it as is.
Co-authored-by: Ryan Christoffersen <[email protected]>
Co-authored-by: Ryan Christoffersen <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
the change request is blocking merge @alexanderbez, could you re-review when you have time? |
@alexanderbez ping - still blocked 🙈 |
Description
this PR adds a new function to the keyring interface, as well as a CLI command to rename a key in the keyring
ref: #9407
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change