The statement "This means, if there are funds in either the rewardAccount or DAOrewardAccount, anyone can move them anywhere." is completely false.
Only the owner of the funds (in this case the DAO itself through a proposal) is able to move the funds. This is ensured by this line:
if (msg.sender != owner || msg.value > 0 || (payOwnerOnly && _recipient != owner))
throw;
msg.sender needs to be the owner, which is the DAO.
The reason why call was used instead of send, was to allow for generic contracts receiving the ether. Since this was the responsibility of the receiver himself, this is not a probem. Because of the rentry exploit it becomes a problem, and in this light, of course send should have been used.
So all comes down to the reentry exploit.
When the code for the DAO was written, we have not been aware of this exploit, therefore there are several places in the code were this can be exploited. So this type of bug exists in several places in the DAO code.
But to say it was engineered for failing, because there is one type of bug in the contract, is absurd.
Yeah... how to boolean logic.
I'll edit that out. [E] Or... it won't let me. Apparently there's a 24-hour limit or something. That's nice, guess I won't be using this platform anymore...
The rest still kind of holds true, though.
As far as using
.callover.send... That explanation doesn't really make a whole lot of sense to me. It was.sendbefore, and was changed to.call..sendworks with contracts, so I don't see why it's necessary, even to support generic contracts as recipients.The only difference between a
.sendand a.callwith no data is that there's much less gas provided, preventing things like this from happening (when the gas amount is correct, that is).So again... why did
.sendneed to be changed to.call? There are only places in the contract where.sendand.callare used appropriately... But this one was specifically changed to be used inappropriately.Still doesn't answer the issue of the backdoor in the
refundmethod, if the fueling goal isn't met.Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit
@cjentzsch It seems to me that you included child DAOs as a safety mechanism that prevents reentrancy attacks. As the funds are isolated within a new contract before they can be withdrawn, that would protect against reentrancy.
If that were true, then it would seem to me that the withdraw-reward mechanism was added later, or by a second programmer, which is why it is not integrated with the child DAO safety system. If the rewards were transfered first to the child DAO instead of being sent to
_recipient, that would isolate the entire withdraw procedure.Downvoting a post can decrease pending rewards and make it less visible. Common reasons:
Submit