Extend acra-keys export/import subcommand #629
Conversation
Extend acra-keys export/import subcommand with V1 keystore support
Added comments for eported types
Lagovas
left a comment
Lagovas
left a comment
There was a problem hiding this comment.
can you add description to PR what actually was done from the general view? like logic of acra-backup which ere implemented only for v1, moved to acra-keys import/export. Keystore v1 extended with implementation of interface X1, X2. Keystore v2 extended with Y1, Y2...
keystore/keystore.go
Outdated
| // Export only public key data. | ||
| ExportPublicOnly ExportMode = 0 | ||
| // Export private and public key data. | ||
| ExportPrivateKeys = (1 << iota) |
There was a problem hiding this comment.
hm, what the logic of such assigning?) 0, 1, 4... it's 000, 001, 100 in binary format..
if it just moved from acra-backup here and these values weren't dumped somewhere and used only internally, we can use more predictable values for that. Just iota or 1 << iota if we want use them as bit masks
There was a problem hiding this comment.
Agree, will fix the mask creation
Extend acra-keys export to work with keyID and key paths
Fixed acra-keys configs
Fixed failing tests
cmd/acra-keys/keys/export_test.go
Outdated
| }, | ||
| { | ||
| KeyKind: keystore.KeyPath, | ||
| ContextID: []byte("testclientid_storage_sym"), |
There was a problem hiding this comment.
you are cheater )) compile arguments programmatically to test both cases ))
There was a problem hiding this comment.
Will add parsing from arguments)
Remove KeyPath KeyID
Added logging
Added additional tests
Fixed failing tests
Fixed general_validation tests
Added invalid cases tests
|
|
||
| if len(exportIDs) != 0 { | ||
| for _, exportID := range exportIDs { | ||
| switch exportID.KeyKind { |
There was a problem hiding this comment.
please, add comment that we additionally verify public keys and do not for private keys due to they are encrypted and will be validated on the decryption step. because in the future a question will arise as why so and do we need validate private keys too
Fixed after reivew
# Conflicts: # CHANGELOG_DEV.md
|
|
||
| // DescribeKeyFile describes key by its purpose path for V1 and V2 keystore | ||
| func DescribeKeyFile(fileName string) (*keystore.KeyDescription, error) { | ||
| description, ok, err := describeV2(fileName) |
What has been done in this PR?
Currently,
acra-keysexport/importcommand supports keys fromV2keystore only, the idea was to add support forV1keystore as well under one tool. But we have different utility that has similar functionality for backup keys ofV1keystore -acra-backup. As the resultacra-backupfunctionality was merged underacra-keysexport/importTechnically, there were introduced new interfaces
keystore.Exporterforexportsubcommand andkeystore.Importerforimportsubcommand. Corresponded_Backuperswere implemented for keystoresV1andV2.The important thing, is that
acra-keysexportinterface was the following - it could be possible to export all keys from keystore via--allflags or export some special key by specifyingexportIDin the format like (client/client_test/storage) - which represent a relative path to the key in the keystore. Since all our subcommands insideacra-keystool operate with a generic key definition (e.gpoison-record,client/{some_client}/symmetric, etc) the same functionality was added foracra-keysexporttoo, but specifying key as path was saved for backward compatibility reasons.Checklist
with new changes