simd keys list

[yaruwangway]

Summary of Bug

when build simd from v0.45, when do simd keys list , i get
Error: Bytes left over in UnmarshalBinaryLengthPrefixed, should read 10 more bytes but have 163

it seems some of the keys cannot be parsed by simd 0.45, maybe some of them are added by other version of simd.

Version

Steps to Reproduce

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[alexanderbez]

What keyring backend? Are these new keys or imported?

[glnro]

I can confirm running the following

$ ./simd version
0.45.0

$ ./simd init test --chain-id test --home ~/.simd1

$ ./simd keys add test-2 --keyring-backend test
- name: test-2
  type: local
  address: cosmos1h526wpl0z55tztts2qpju0tr8lmu23vnsa98ww
  pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AjyCBWrIpJX/5uPkFSwdyqZInNmAgwq2p6RCrdyBvDXT"}'
  mnemonic: ""

$ ./simd keys list --keyring-backend test
Error: Bytes left over in UnmarshalBinaryLengthPrefixed, should read 10 more bytes but have 164

[yaruwangway]

@alexanderbez , local key, keyring-backend test, this is an issue from testing tendermint key-migration by cosmovisor pre-upgrade.

i did not change my key or anything, it was working with simd v0.45 to show the key, it suddenly does not work , i wonder if it is because i did tendermint key migration.

does tendermint key migration also migration local account address key ?

[yaruwangway]

@glnro can you try simd v0.46, to list the keys.

[glnro]

I had no problem doing the same with 0.46.0-beta2

[yaruwangway]

@alexanderbez , local key, keyring-backend test, this is an issue from testing tendermint key-migration by cosmovisor pre-upgrade.

i did not change my key or anything, it was working with simd v0.45 to show the key, it suddenly does not work , i wonder if it is because i did tendermint key migration.

does tendermint key migration also migration local account address key ?

confirmed from tendermint team, this is not related to tendermint key migration !

[glnro]

Fwiw no problem running this on v7.0.2 of gaia, just simapp

[tac0turtle]

@AmauryM I saw you are looking at the crypto package. Did you come across anything special?

[glnro]

Update, when working off of sdk v0.46.0-beta2 in our rho base branch, I encounter the following when trying to set up a local chain:

$ gaiad keys list --keyring-backend test
migrate err: "unable to unmarshal item.Data, err: Bytes left over in UnmarshalBinaryLengthPrefixed, should read 10 more bytes but have 166"Error: no registered implementations of type types.PubKey

[glnro]

@alexanderbez btw these are all new keys

[amaury1093]

Hey @glnro and @yaruwangway, I can take a look at this issue.

I can think of 3 scenarios:

1. Create a key using v0.45, and simd keys list using v0.45 errors (Repro: simd keys list #11939 (comment))
2. Create a key using v0.46, and simd keys list using v0.46 errors (Repro: simd keys list #11939 (comment))
3. Create a key using v0.45, and simd keys list using v0.46 errors (no repro yet)

Does this seem correct?

[yaruwangway]

hi, a bit more info:
create a key by simd v0.45 (lets call it 045key), create a key by simd v0.46 (lets call it 046key),

• simd v0.45 keys show 045key works, simd v0.46 keys show 045key works,
• simd v0.45 keys show 046key fails, simd v0.46 keys show 046key works,
• simd v0.45 keys list fail, simd v0.46 keys list works.

[yaruwangway]

so it seems the decoding of keys by v0.45 is not compatible with other version keys.

[amaury1093]

Hey, unfortunately I couldn't reproduce any of the errors above :(. Here's the full bash script I used: https://gist.github.com/amaurym/e6dbe3363b1b2fbd83ff0d415a52127b. I tested with:

• v0.45.4
• v0.46.0-beta2

@yaruwangway @glnro could you provide a similar bash script, where you could reproduce all errors you found? Ideally using simapp (not gaiad). Thanks!

[yaruwangway]

@AmauryM , the script you used does not include $v046_NODE keys add and with $v045_NODE keys list ? use 0.45 list a key created by 0.46

[amaury1093]

@yaruwangway In v0.46 we migrated keyriing from amino to protobuf. Doing what you say would require writing additional logic to migrate from proto back to amino, which I would like to avoid (amino is being deprecated).

What's your use case to list v046 keys using a v045 node?

[glnro]

@AmauryM I think one of the issues I'm running into for example is I've created keys on my local machine while testing with both binaries as we've had to go back and forth with versions during our work. Still trying to figure out how this is affecting our e2e test and I'm writing another test to confirm what you posted above.

[yaruwangway]

list v046 keys using a v045 node:
Error: Bytes left over in UnmarshalBinaryLengthPrefixed, should read 10 more bytes but have 164

list v045 keys using a v046 node: works!

list v045 keys using a v045 node: works!
list v046 keys using a v046 node: works!

[yaruwangway]

are the above cases expected, due to migrated keyring from amino to protobuf ?

[amaury1093]

The case "list v046 keys using a v045 node" is not expected, and should fail. Users shouldn't be able to show newer keys with older software.

[yaruwangway]

ok, thank you!

[faddat]

We seem to be hitting exactly this:

• 47 done jq needs fixed interchain-security#824