Duplicate baker pkh in signatory list

[michaelkernaghan]

Summary

When importing a key that already exists in a vault, signatory-cli import should warn or prevent the duplicate import.

Current Behavior

YubiHSM (and potentially other backends) allows importing the same secret multiple times with different IDs:

Public Key Hash:    tz1TfGsL6o754mfxcntSzDDTh9RrjZVNocjP
Vault:              YubiHSM
ID:                 bce7
Status:             ACTIVE

Public Key Hash:    tz1TfGsL6o754mfxcntSzDDTh9RrjZVNocjP
Vault:              YubiHSM
ID:                 caa0
Status:             ACTIVE

Proposed Solution

Add a pre-import check to signatory-cli import that:

1. Lists existing keys in the target vault
2. Compares the public key hash of the key being imported
3. Warns user if duplicate exists, with option to proceed or abort

This check should be implemented for all backends, not just YubiHSM.

Related

• Key/Backend paring config #106 - Key/Backend pairing config (inconsistency in ID semantics across vaults)

[jevonearth]

Marginally related to #106

The ID: property here represents the identity of a key on yubihsm. I think that yubihsm can import the same secret many times, and it will give a different ID to each (identical) secret. We could have signatory-cli enforce/prevent import of duplicate secrets, but that won't eliminate the possibility of having dupe keys. We should handle this some other way in signatory.

This issue also highlights an inconsistency in the Vault/Key abstraction around ID:. In yubi, ID is the identity of a specific key on the yubiHSM, but on ledger the ID is derived from the root key that is provisioned on the ledger.