Development resources at your finger tips
Build with the coolest Web3 projects
Recurring funding for Open Source
Learn about Web3 & earn rewards
Show appreciation for each other
Meet fellow developers, designers, futurists and more. Collaborate and BUIDL awesome projects together.
Discover great web3 organizations, work on meaningful projects and build relationships with like minded people. Browse Tribes
Meet the top hunters and contributors from our community.
In partnership with Protocol Labs, we’re excited to welcome builders from everywhere to APOLLO, your mission control to engage with the builder…
Gitcoin is GDPR complaint. Learn more in
Gitcoin's Terms & Conditions.
Check out the Issue Explorer
Looking to fund some work? You can submit a new Funded Issue here.
Logic contracts registered in an app are currently open to the same attack as the [2nd Parity Wallet hack](https://blog.zeppelinos.org/parity-wallet-hack-reloaded/). Given that we one of our goals is to make deployments more secure, I'd like to address this at least before the anniversary of the hack (November 7th).
All jokes aside, we are not initializing logic contracts as they are deployed via `zos push`. This will also be true as we move onto the new _constructor contracts_ pattern.
These are the options that come to mind to prevent the issue:
1- Push forward https://github.com/zeppelinos/zos-lib/issues/33, which prevents any calls whatsoever to a logic contract. This is the safest solution by far. It requires a new feature altogether in Solidity though, or meddling with the assembly code, which would break verifications, and potentially introduce unexpected bugs. However, even with the new feature, it requires the user to change their contracts to be used with zOS, something we're trying to avoid (unless we modify it automatically from the CLI before deployment).
2- Check the contract code for any SELFDESTRUCT calls. We could either check the binary (which would provide little info the user as where the call is issued, and may also fire some false positives if there is raw data with the same value as the opcode), or the source code of the contract and all its ancestors. The best we can do here is print a warning to the user, indicating that contract _could be_ insecure.
3- Force initialization of logic contracts when registered. This adds a lot of burden to the end user, who needs to provide "fake" params (which will never be used) for every contract to be registered. It also doesn't protect against this problem, since a SELFDESTRUCT in the contract logic could be callable regardless of the initialization parameteres.
I'd go with (2) for the time being. Thoughts?