Open mshakeg opened 3 weeks ago
Thank you very much for your proposal! While I agree, it would be nice to have it fully automated, we have been reluctant to upload private keys to GitHub actions and prefer the manual step.
Hi @nlordell is this particular mnemonic only used for the safe singleton factory? if so then I don't see the concern even if the private key is somehow leaked(which should hopefully never happen if proper access control to github secrets are setup). I just think with a new chain launching every other day, automating this will save you guys a bunch of time.
if so then I don't see the concern
if the key is leaked then it will be impossible to deploy safe contracts to canonical addresses to the chain, since the nonce will be used and the resulting factory address will be different.
@mmv08 agreed, what I'm getting at is I don't see what's exceptional about storing the key in gh secrets vs locally on devs machine, why is it more likely to be leaked in the former relative to the latter?
In fact if devs store the private key in plain text unencrypted then gh secrets is probably way more secure.
In fact if devs store the private key in plain text unencrypted
Don't worry, we don't :stuck_out_tongue:.
why is it more likely to be leaked in the former relative to the latter?
I don't think it is more likely to be leaked, it is just increasing the probability of leaking the secret by adding a new system that has access to it. Also, there are some different attack vectors that need to be considered when using secrets in GH actions, and as @mmv08 mentioned this secret cannot be rotated if it is leaked.
Note that we have some proposals on how to make a completely permissionless CREATE2
deployer that will hopefully be made possible with EIP-7702: https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code-for-one-transaction/19923/161?u=nlordell
@nlordell
Don't worry, we don't 😛.
Nice, what hardhat extension are y'all using to securely manage keys?
wrt EIP-7702, it sounds promising, but it also sounds like it'll only work on EVM chains that supports the proposed tx type, not sure how widely adopted this will be, but at least initially it won't work for almost all EVM chains, so we'll still have to rely on this factory to deploy canonical instances of Safe.
Nice, what hardhat extension are y'all using to securely manage keys?
We use 1Password CLI in our flows.
but it also sounds like it'll only work on EVM chains that supports the proposed tx type
True :disappointed: - hoping 7702 takes off though :stuck_out_tongue:.
I would like to propose an enhancement to the deployment process of the Safe Singleton Factory to new chains. Currently, the process requires intervention from the Safe team, which can introduce delays for deployments on new chains. To streamline this process and ensure timely deployments, I suggest automating the deployment using GitHub Actions.
Current Process:
The current workflow involves manually deploying the factory from the deployer account (0xE1CB04A0fA36DdD16a06ea828007E35e1a3cBC37). Although there is an existing GitHub Action that validates if the deployer account has sufficient funds and marks the issue as
ready-to-deploy
, the final deployment step still requires manual intervention.Proposed Enhancement:
To fully automate the deployment process, I propose the following:
Securely Load Mnemonic into GitHub Actions:
Enhance the Existing GitHub Action:
yarn estimate-compile
andyarn submit
.Proposed Workflow:
By automating the deployment process, we can significantly reduce the time required to deploy the Safe Singleton Factory on new chains, ensuring a more efficient and responsive workflow. Ensure nonce 0 is used for the deployment tx.
FYI GPT4 drafted.