polkadot-v0.9.42 update bricks local keystore key retrieval

[clangenb]

The keys are there, but we fail to retrieve them:

rm -rf my_trusted_keystore/
root@d655c1836484:/opt/shared/integritee-worker/bin# RUST_LOG=info ../bin/integritee-cli trusted --mrenclave HQ7yBQQMnyVKfUgNfkrc5LbNwUgFmJeKUWuZCephXbcN new-account
[2023-06-23T12:16:13Z INFO  integritee_cli::trusted_base_cli] new account 5HnDAGhGbhWkc2AvUgqBLYfPnVyCSvcuMNgDku3VpgQ9aZP8
root@d655c1836484:/opt/shared/integritee-worker/bin# cat my_trusted_keystore/HQ7yBQQMnyVKfUgNfkrc5LbNwUgFmJeKUWuZCephXbcN/6163636ffcd4df89e7eb1f928fe74c53ea8ad69bc3fbdb40ab48c1dad33c396da2953205
"already body maze organ clock code coast curve desert fluid goddess wisdom"root@d655c1836484:/opt/shared/integritee-worker/bin#
root@d655c1836484:/opt/shared/integritee-worker/bin# ../bin/integritee-cli trusted --mrenclave HQ7yBQQMnyVKfUgNfkrc5LbNwUgFmJeKUWuZCephXbcN balance 5HnDAGhGbhWkc2AvUgqBLYfPnVyCSvcuMNgDku3VpgQ9aZP8
thread 'main' panicked at 'key does not exist', cli/src/trusted_command_utils.rs:125:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
root@d655c1836484:/opt/shared/integritee-worker/bin# RUST_LOG=info ../bin/integritee-cli trusted --mrenclave HQ7yBQQMnyVKfUgNfkrc5LbNwUgFmJeKUWuZCephXbcN list-accounts
[2023-06-23T12:21:50Z INFO  integritee_cli::trusted_base_cli] sr25519 keys:
5HnDAGhGbhWkc2AvUgqBLYfPnVyCSvcuMNgDku3VpgQ9aZP8
[2023-06-23T12:21:50Z INFO  integritee_cli::trusted_base_cli] ed25519 keys:
5HnDAGhGbhWkc2AvUgqBLYfPnVyCSvcuMNgDku3VpgQ9aZP8

This roundrip should be a unit test

[OverOrion]

Some more info:

The key retrieval fails, because the path it tries to open does not exist:
(see fn key_phrase_by_type() and key_file_path)

$11 = std::path::PathBuf {inner: "my_trusted_keystore/CYP3nCBtabGKPxThTUFCgCa5Cw2Xkumw5iLYfqQKJtqm/737232357cfac413361f4dedc0533253600be1d977e14168a3ce4e942cf1dd7062a4d143"}

The public was 7cfac413361f4dedc0533253600be1d977e14168a3ce4e942cf1dd7062a4d143 and when I ran the second command the following sr25119 ACCOUNT keys were in the keystore:

store has the following sr25519 keys: [
    c0c85341da0a7f7964ff61953f86a55aa6e69ade51f2ce06ed33af1ee1437b11 (5GRUZSFC...),
    7cfac413361f4dedc0533253600be1d977e14168a3ce4e942cf1dd7062a4d143 (5EtaHekf...),
    c49501bb28979bf7872ef60fd7fa4a2d2e14c540d5123a922393ab48d5f5947e (5GWTWMBf...),
]

in key_file_path:

key = "7cfac413361f4dedc0533253600be1d977e14168a3ce4e942cf1dd7062a4d143"
key_type = "73723235"
buf = std::path::PathBuf {inner: "my_trusted_keystore/CYP3nCBtabGKPxThTUFCgCa5Cw2Xkumw5iLYfqQKJtqm"}

the following files are in that dir:

CYP3nCBtabGKPxThTUFCgCa5Cw2Xkumw5iLYfqQKJtqm] szp/polkadot-v0.9.42 $ ls -l
total 12
-rw------- 1 ubuntu ubuntu 73 jún   23 16:15 6163636f7cfac413361f4dedc0533253600be1d977e14168a3ce4e942cf1dd7062a4d143
-rw------- 1 ubuntu ubuntu 72 jún   23 16:14 6163636fc0c85341da0a7f7964ff61953f86a55aa6e69ade51f2ce06ed33af1ee1437b11
-rw------- 1 ubuntu ubuntu 76 jún   23 16:08 6163636fc49501bb28979bf7872ef60fd7fa4a2d2e14c540d5123a922393ab48d5f5947e

It seems that when the keys were placed in the folder they are made with the wrong key_type.

[OverOrion]

The problem was that when a new account was created it was put into the keystore with ACCOUNT type, but the retrieval was done with sr25, this is what led to this behaviour.

It was fixed in ecfe65f.