Repository navigation
Description
What version are you using?
stellar-cli 28.1.0
What did you do?
I created a secure-store identity with stellar-cli 26.0.0, the last release before identity files started caching the public key:
Setup:
$ cargo +1.92.0 install --locked stellar-cli --version 26.0.0Create the key:
$ stellar keys generate --secure-store alice
ℹ️ Saving a new key to your operating system's secure store: secure_store:org.stellar.cli-alice
✅ Key saved with alias alice3 in "~/.config/stellar/identity/alice.toml"
$ cat ~/.config/stellar/identity/alice.toml
entry_name = "secure_store:org.stellar.cli-alice"
Call the stellar keys address alice with --hd-path and without it:
$ stellar keys address alice --hd-path 3
$ stellar keys address aliceUpdate to the latest cli:
$ cargo install --locked stellar-cli --version 28.1.0Call again stellar keys address alice with --hd-path and without it:
$ stellar keys address alice --hd-path 3
$ stellar keys address aliceWhat did you expect to see?
The --hd-path 3 lookup to apply only to that one command, and a following stellar keys address alice to output the default (index 0) address, in the same way that it did on stellar-cli 26.0.0:
$ stellar version
stellar 26.0.0 (60f7458e7ecffddf2f2d91dc6d0d2db4fab03ecc)
$ stellar keys address alice --hd-path 3
GAAW3ZDAZYNF6KGPJA7MMMPM6POYY4U4EFK5SWYYA5F5PMVXS2IMNQ3I
$ stellar keys address alice
GC4KDMBE3AVFDZ75ZJJPOX7QET2555NMWK5DKOLRPSIU4KH2WQSE2HBJ # ✅
$ stellar keys address alice --hd-path 0
GC4KDMBE3AVFDZ75ZJJPOX7QET2555NMWK5DKOLRPSIU4KH2WQSE2HBJWhat did you see instead?
The --hd-path 3 lookup seemed to make that the default, and a following stellar keys address alice to output the index 3 address:
$ stellar version
stellar 28.1.0 (c0f4d0da891bbf214c08b8c5035ae6db80e9a3bd)
$ stellar keys address alice --hd-path 3
GAAW3ZDAZYNF6KGPJA7MMMPM6POYY4U4EFK5SWYYA5F5PMVXS2IMNQ3I
$ stellar keys address alice
GAAW3ZDAZYNF6KGPJA7MMMPM6POYY4U4EFK5SWYYA5F5PMVXS2IMNQ3I # ❌
$ stellar keys address alice --hd-path 0
GC4KDMBE3AVFDZ75ZJJPOX7QET2555NMWK5DKOLRPSIU4KH2WQSE2HBJOn inspection it seems that the hd-path 3 has been saved with the key:
The one-off lookup rewrote the identity file, and from then on the identity resolves to the index 3 account:
$ cat ~/.config/stellar/identity/alice.toml
entry_name = "secure_store:org.stellar.cli-alice"
public_key = "GAAW3ZDAZYNF6KGPJA7MMMPM6POYY4U4EFK5SWYYA5F5PMVXS2IMNQ3I"
hd_path = 3
Note the emojis are added into the above output for effect.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsBacklog (Not Ready)
Activity
duongynhi000005-oss commentedon Oct 26, 2026
Hi! I would like to fix this issue.
Root Cause
In
Args::read_key_with_secure_store_cache(cmd/soroban-cli/src/config/locator.rs), when an uncached legacySecret::SecureStoreidentity (public_key: None, hd_path: persisted_hd_path) is read with a one-off--hd-path Nflag (hd_path = Some(3)),effective = hd_path.or(*persisted_hd_path)evaluates toSome(3)andself.write_key(key_or_name, &migrated)writespublic_key: Some(pk_at_3), hd_path: Some(3)back to~/.config/stellar/identity/<name>.toml. Every subsequent command without--hd-paththen resolves to index3instead of the identity's original default (persisted_hd_path, index0).Proposed Fix
read_key_with_secure_store_cache, only persist the cachedpublic_keyback to disk wheneffective.unwrap_or_default() == persisted_hd_path.unwrap_or_default()(and preservehd_path: *persisted_hd_pathin the written identity file).effectivediffers frompersisted_hd_path(a one-off--hd-path Nlookup), return the derivedSecret::SecureStorein memory for the current command without mutating the identity file on disk.I have prepared the fix on my fork branch
duongynhi000005-oss/stellar-cli:fix/issue-2777-secure-store-hd-path-cache(commitbb0c86c1) and can open a PR once assigned.