Right now the CLI reads the signing key from CRE_ETH_PRIVATE_KEY in .env (or a raw env var). That means the key sits unencrypted on disk for as long as the project exists, which isn't great even for testnet work.
Foundry solved this a while back with cast wallet import <name> --interactive - it prompts for the key + a password once, encrypts it (ERC-2335), and after that you just do --account <name> and get a password prompt instead of a plaintext key anywhere in the project.
Would be great if cre-cli had something similar, e.g.
cre wallet import <name> - prompt for pk + password, store encrypted locallycre workflow simulate ... --account <name> - password prompt instead of reading .envcre wallet list - list configured accounts, obviously without exposing the keys
Since a lot of us are coming from Foundry, this would match a pattern people already expect and cut down on keys ending up in .env files, shell history, or accidentally committed.
Not attached to ERC-2335 specifically if there's a preferred format on your end - just flagging the gap. Happy to help implement once there's agreement on direction.
Right now the CLI reads the signing key from CRE_ETH_PRIVATE_KEY in .env (or a raw env var). That means the key sits unencrypted on disk for as long as the project exists, which isn't great even for testnet work.
Foundry solved this a while back with
cast wallet import <name> --interactive- it prompts for the key + a password once, encrypts it (ERC-2335), and after that you just do--account <name>and get a password prompt instead of a plaintext key anywhere in the project.Would be great if cre-cli had something similar, e.g.
cre wallet import <name>- prompt for pk + password, store encrypted locallycre workflow simulate ... --account <name>- password prompt instead of reading .envcre wallet list- list configured accounts, obviously without exposing the keysSince a lot of us are coming from Foundry, this would match a pattern people already expect and cut down on keys ending up in .env files, shell history, or accidentally committed.
Not attached to ERC-2335 specifically if there's a preferred format on your end - just flagging the gap. Happy to help implement once there's agreement on direction.