Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

forge script should support loading private key from environment #7814

Closed
yonadaa opened this issue Apr 29, 2024 · 1 comment
Closed

forge script should support loading private key from environment #7814

yonadaa opened this issue Apr 29, 2024 · 1 comment
Labels
T-feature Type: feature

Comments

@yonadaa
Copy link

yonadaa commented Apr 29, 2024

Component

Forge

Describe the feature you would like

It would be useful if forge script had some way to load an account from a private key in the environment without passing the private key as a flag (similar to how using the --aws flag loads AWS_KMS_KEY_ID).

Currently a private key can be provided to forge script with the --private-key flag or by reading it in the script:

uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");
vm.startBroadcast(deployerPrivateKey);

It is not always appropriate to use a flag because it requires manipulating the private key in the command line (as opposed to using .env). On the other hand, loading the key directly in the script limits the script to working with the private key signer.

Additional context

No response

@yonadaa yonadaa added the T-feature Type: feature label Apr 29, 2024
@klkvr
Copy link
Member

klkvr commented May 1, 2024

you can use --interactive for entering private key interactively without leaving it in command-line history.
also you can use foundry keystores to store arbitrary private keys in an encrypted file and simply use --account keystore_name

we could consider adding env variable or argument for private key path but imo storing plain private keys in files in working directories is an antipattern and is not more secure than having them in command line history, so not sure if we should encourage such workflows while we already have nicely-supported keystores

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-feature Type: feature
Projects
None yet
Development

No branches or pull requests

3 participants