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

Add rule to prohibit calls of .send #5

Merged
merged 4 commits into from
Nov 14, 2017

Conversation

TristanH
Copy link
Contributor

@TristanH TristanH commented Nov 11, 2017

In response to the Augur Bug Bounty: Prohibit use of send

Let me know if there are any fixes/improvements needed :)

Also, currently looking at how to not detect e.g user-defined classes with send functions, but I'm not sure if there's a way to detect that the type of a callee (in the test's case msg.sender) is an address. Any ideas?

test/no-send.js Outdated
}
};

describe ('[RULE] no-send', function () {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please change description to [RULE] no-send: Rejections (this is convention throughout Solium)

rules/no-send.js Outdated

schema: [],

fixable: 'code'
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove fixable: 'code' - this property is set only if the rule supplies at least 1 fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, good catch :) I had a fixable in before (changing send to transfer) but I removed it

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that must've been the case (has happened with me too!)

@TristanH
Copy link
Contributor Author

TristanH commented Nov 12, 2017

@duaraghav8 I did some digging and it appears there is no way in solparse to detect that the type of an Identifier (in the test example's case msg.sender) is address. Is this true?

If so, some options:

  • Add the ability to check the type of an arbitrary Identifier to solparse (not sure how involved this will be...)
  • Merge this rule anyways and ignore the largely rare case of folks writing their own function called specifically send

@duaraghav8
Copy link
Owner

@TristanH That's right, I've had the same thought before of the rare case where user might have defined a send().

  • Deducing a type from given identifier is beyond the scope of solparse (since its only responsible for parsing code into AST. So it doesn't know, for eg, where the object foo's bar property is coming from. That is a job more suited for a Symbol Table (make info about all declarations & definitions accessible to each rule Ethlint#83)
  • I had put a lot of thought into it and decided to leave solving for this extremely rare case. There are techniques but the time investment is not worth it.

So leave out this edge case.

@TristanH
Copy link
Contributor Author

Gotcha -- that's what I suspected. Thanks for the detailed explanation, the symbol table would be awesome if it was implemented, but I agree probably out of scope :)

In that case I think this PR should be good to go!

@duaraghav8
Copy link
Owner

It is :) Allow me to review all other PRs, merging will begin in ~2 days

@duaraghav8 duaraghav8 merged commit 77bf603 into duaraghav8:master Nov 14, 2017
@duaraghav8
Copy link
Owner

duaraghav8 commented Nov 14, 2017

@TristanH merged!
but There's a tiny issue - any special reason you used calleeNode.property.type in isSend()? The AST nodes don't have a property attribute (test fails)

Also callee.parent is undefined, so isSend function always gets sent an undefined and thus causes exception.

@duaraghav8
Copy link
Owner

20 passing (326ms)
  1 failing

  1) [RULE] no-send: Rejections
       should reject contracts using send:
     TypeError: Cannot read property 'type' of undefined
      at isSend (rules/no-send.js:10:20)
      at EventEmitter.inspectCallExpression (rules/no-send.js:34:8)
      at EventGenerator.leaveNode (node_modules/solium/lib/utils/node-event-generator.js:36:16)
      at Controller.leave (node_modules/solium/lib/solium.js:162:24)
      at Controller.exec (node_modules/sol-explore/lib/traverse.js:99:21)
      at Controller.traverse (node_modules/sol-explore/lib/traverse.js:148:8)
      at node_modules/sol-explore/lib/traverse.js:137:17
      at Array.forEach (native)
      at Controller.traverse (node_modules/sol-explore/lib/traverse.js:133:22)
      at node_modules/sol-explore/lib/traverse.js:140:18
      at Array.forEach (native)
      at node_modules/sol-explore/lib/traverse.js:139:11
      at Array.forEach (native)
      at Controller.traverse (node_modules/sol-explore/lib/traverse.js:133:22)
      at node_modules/sol-explore/lib/traverse.js:137:17
      at Array.forEach (native)
      at Controller.traverse (node_modules/sol-explore/lib/traverse.js:133:22)
      at node_modules/sol-explore/lib/traverse.js:140:18
      at Array.forEach (native)
      at node_modules/sol-explore/lib/traverse.js:139:11
      at Array.forEach (native)
      at Controller.traverse (node_modules/sol-explore/lib/traverse.js:133:22)
      at node_modules/sol-explore/lib/traverse.js:140:18
      at Array.forEach (native)
      at node_modules/sol-explore/lib/traverse.js:139:11
      at Array.forEach (native)
      at Controller.traverse (node_modules/sol-explore/lib/traverse.js:133:22)
      at Object.module.exports [as traverse] (node_modules/sol-explore/lib/traverse.js:169:28)
      at EventEmitter.lint (node_modules/solium/lib/solium.js:154:14)
      at Context.<anonymous> (test/no-send.js:28:20)

@TristanH
Copy link
Contributor Author

Oh crap, sorry about that @duaraghav8 I'm looking now.

@TristanH
Copy link
Contributor Author

TristanH commented Nov 14, 2017

Ah, I just passed in callee.parent instead of just callee to isSend on line 35... fix incoming. Sorry about that, no clue how it ended up there.

@TristanH
Copy link
Contributor Author

TristanH commented Nov 14, 2017

And yeah, also property is not defined sometimes (I believe it is only defined when the function is an attribute of an object, otherwise it's undefined. Should have tested more!) Will address that too.

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

Successfully merging this pull request may close these issues.

2 participants