No funded issue found.
Check out the Issue Explorer
Be the OSS Funding you wish to see in the world.
Looking to fund some work? You can submit a new Funded Issue here .
Time left
Opened
Issue Type
Workers Auto Approve
Project Type
Time Commitment
Experience Level
Permissions
Accepted
Reserved For
Logic contracts can be "accidentally killed"
zeppelinos
JavaScript, Solidity
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?
Setup your profile
Tell us a little about you:
Skills
No results found for [[search]] .
Type to search skills..
Bio Required
[[totalcharacter]] / 240
Are you currently looking for work?
[[ option.string ]]
Next
Setup your profile
Our tools are based on the principles of earn (💰), learn (📖), and meet (💬).
Select the ones you are interested in. You can change it later in your settings.
I'm also an organization manager looking for a great community.
Back
Next
Save
Enable your organization profile
Gitcoin products can help grow community around your brand. Create your tribe, events, and incentivize your community with bounties. Announce new and upcoming events using townsquare. Find top-quality hackers and fund them to work with you on a grant.
These are the organizations you own. If you don't see your organization here please be sure that information is public on your GitHub profile. Gitcoin will sync this information for you.
Select the products you are interested in:
Out of the box you will receive Tribes Lite for your organization. Please provide us with a contact email:
Email
Back
Save
