vacuumlabs/cardano-hw-cli

Incompatible node cold verification file type

Closed this issue · 7 comments

gitmachtl commented

When the support for pool cold keys via hw-wallets started, the generated verification key files via cardano-hw-cli looked like:

{
    "type": "StakePoolVerificationKey_ed25519",
    "description": "Stake Pool Operator Verification Key",
    "cborHex": "58205474de0dd906dae02e33cad45bb24a21f1ade6af57457b6ea171985412cd35d0"
}

With the latest (or some later version), this was changed into:

{
    "type": "StakePoolVerificationKeyShelley_ed25519",
    "description": "Stake Pool Operator Verification Key",
    "cborHex": "58205474de0dd906dae02e33cad45bb24a21f1ade6af57457b6ea171985412cd35d0"
}

So the type was changed from StakePoolVerificationKey_ed25519 to StakePoolVerificationKeyShelley_ed25519.

Cardano-CLI does not like that change and exits with:

Command failed: stake-pool id  Error: pool.node.vkey: TextEnvelope type error:  Expected: StakePoolVerificationKey_ed25519 Actual: StakePoolVerificationKeyShelley_ed25519

Simplest solution would be to set it back to the original type within cardano-hw-cli. Otherwise we would need to change that type value after the key generation manually or in the calling scripts. In the current setup, its preventing users from creating pools with hw-cold-keys.

@janmazak @davidmisiak

getwildr commented

Thanks for the quick taking into consideration, I've been also impacted by this.
Also, so as to get a bit further, I was wondering if it would be correct/if you could add a "Hardware" mention in description of all the produced keys ?
So that we can better detect we need cardano-hw-cli instead of cardano-cli while operating using these keys.
Thanks for your feedback,

gitmachtl commented

Also, so as to get a bit further, I was wondering if it would be correct/if you could add a "Hardware" mention in description of all the produced keys ?

I automatically do this in my scripts already, thats the thing the scripts are searching for to see if its a Hardware key or a cli key. However, the presents of a .hwsfile should also do the same job. And if only the vkey is needed, there is no difference at all in the processing.

getwildr commented

@gitmachtl
Sure, we do that too.
But I mean, if that's OK for the team here,
Might be better to add something here once rather than having all projects maintainers to do so every time on every project.

janmazak commented

The type should be fixed (ecfb5ca is part of develop).
Can the description be basically whatever?

Based on your suggestion, I'd propose to add "Hardware" at the beginning of each description we use, e.g.
"Stake Verification Key" -> "Hardware Stake Verification Key". Would that be OK?

getwildr commented

The type should be fixed (ecfb5ca is part of develop).
Can the description be basically whatever?

Based on your suggestion, I'd propose to add "Hardware" at the beginning of each description we use, e.g.
"Stake Verification Key" -> "Hardware Stake Verification Key". Would that be OK?

It would be great, thanks 🙏

gitmachtl commented

The type should be fixed (ecfb5ca is part of develop). Can the description be basically whatever?

Based on your suggestion, I'd propose to add "Hardware" at the beginning of each description we use, e.g. "Stake Verification Key" -> "Hardware Stake Verification Key". Would that be OK?

In the SPO tools and CN tools f.e. we correct the description to "Stake Hardware Verification Key" since the beginning. To mark the a key belongs to a HW key. Or "Payment Hardware Verification Key". But as long as the Keyword "Hardware" is in the description, i think thats a good solution.

For the governance keys, the suggestion is:
Governance Hardware Signing File, Governance Hardware Verification Key
or with Hardware in front.

  • 👍1