fix: get_signing_identity's MUSE_AGENT_KEY_FD path derived with entity_type=ENTITY_HUMAN, contradicting hdkeys.py's own ENTITY_AGENT example (musehub#205)
derive_identity_key(sub_seed, hub=hub) in the MUSE_AGENT_KEY_FD branch never passed entity_type, defaulting to ENTITY_HUMAN. But this sub-seed comes from derive_agent_sub_seed() -- an agent's own already-isolated SLIP-0010 sub-tree -- and derive_identity_key's own module docstring gives the documented correct usage as entity_type=ENTITY_AGENT ('Agent slot 0's identity key'). Every key derived via this path was rooted at the wrong entity_type branch of the agent's own sub-tree.
Confirmed via AskUserQuestion this is a real behavior change, not purely cosmetic: entity_type is baked into the HD derivation path, so this changes the actual derived key for any identity using this flow. Chose to fix the derivation (matching hdkeys.py's own documented example) rather than relabel the docstring to describe the bug as intended behavior -- the latter would leave the exact latent risk the ticket itself flags: any future code that independently re-derives 'the agent's identity key' following the documented ENTITY_AGENT example would compute a different key than config.py actually produces, and signature verification would break.
Confirmed empirically that entity_type genuinely changes the derived key (different private_bytes for ENTITY_AGENT vs ENTITY_HUMAN from the same sub-seed), then verified the full real path end-to-end: derived a sub-seed, piped it through a real fd into muse commit --sign, and muse verify-commit confirmed the resulting signature is valid.
Semantic Changes
5 symbols
Files Changed
~2
1261 in snapshot
0 comments
muse hub commit comment sha256:e6186c2a5be8e7a1361b66ad64d74d3ed1865f3e713c55e7931b4c983e3c9df6 --body "your comment"
No comments yet. Be the first to start the discussion.