Code Monkey home page Code Monkey logo

surya's Introduction

get in touch with Consensys Diligence
[ ๐ŸŒ ๐Ÿ“ฉ ๐Ÿ”ฅ ]



npm Build Status

Sลซrya, The Sun God: A Solidity Inspector

Surya is an utility tool for smart contract systems. It provides a number of visual outputs and information about the contracts' structure. Also supports querying the function call graph in multiple ways to aid in the manual inspection of contracts.

Currently only supports Solidity but we hope to extend the tool to encompass other languages.

The name stems from the sun deity Surya

Why the sun, you ask? Because "sun" in latin and portuguese is Sol.

Getting Started

Install it via NPM:

npm install -g surya

NOTE: In order to view the graph output, you need to have graphviz installed, so that you can run the dot command.

Currently, however, the easiest way to use Surya in your project might be through VSCode's Solidity Auditor extension created by @tintinweb

vscode-solidity-auditor-interactive-graph

Command List

Surya takes in a --no-color flag with any command that disables the colors in the output making it effectively plain text.

All the commands that take in an array of files also take in a flag (-i/--import) that resolves file imports automatically. Please be aware that in the case you use Truffle's "node_modules" remapping import statements, Surya searches up the project directory recursively until it finds a contracts directory in the Truffle project up until the directory you ran the command in. This is so that we try to prevent any kind of path traversal vulnerabilities that could come from exposing Surya as a service.

All the commands that take in an array of files also take in a flag (-c/--content) that allows you to pass the actual source code contents as an argument instead of a file path (mostly useful when Surya is being used as another package's dependency).

The -i and -c flags are mutually exclusive.

graph

The graph command outputs a DOT-formatted graph of the control flow.

surya graph contracts/**/*.sol | dot -Tpng > MyContract.png

There is new flag (-s/--simple) that amkes the command chart only the contract call graph, instead of the function call graph. It's super useful for higher-level analyses!

Accepted flags

  • -i/--import - Resolve all imports automatically by fetching the right files.
  • -c/--content - Allow passing in file contents as arguments instead of file paths.
  • -s/--simple - Only show calls between contracts, without specifying the functions.
  • -m/--modifiers - Enable printing edges from functions to modifiers (when the latter are invoked in the function definitions).
  • -l/--libraries - Disable printing edges from functions to libraries when the "Using ... for" syntax is in use (to prevent libraries like SafeMath from polluting the call graph).

ftrace

The ftrace command outputs a treefied function call trace stemming from the defined "CONTRACT::FUNCTION" and traversing "all|internal|external" types of calls. External calls are marked in orange and internal calls are uncolored.

surya ftrace APMRegistry::_newRepo all MyContract.sol

Accepted flags

  • -i/--import - Resolve all imports automatically by fetching the right files.
  • -c/--content - Allow passing in file contents as arguments instead of file paths.
  • -j/--json - Return a JSON object instead of a treefied function call trace (mostly useful when Surya is being used as another package's dependency).

flatten

The flatten command outputs a flattened version of the source code, with all import statements replaced by the corresponding source code. Import statements that reference a file that has already been imported, will simply be commented out.

surya flatten MyContract.sol

describe

The describe command shows a summary of the contracts and methods in the files provided.

surya describe *.sol

Functions will be listed as:

  • [Pub] public
  • [Ext] external
  • [Prv] private
  • [Int] internal

A yellow ($)denotes a function is payable.

A red # indicates that it's able to modify state.

Accepted flags

  • -i/--import - Resolve all imports automatically by fetching the right files.
  • -c/--content - Allow passing in file contents as arguments instead of file paths.

inheritance

The inheritance command outputs a DOT-formatted graph of the inheritance tree. For Windows machines, the > should be replaced with -o.

surya inheritance MyContract.sol | dot -Tpng > MyContract.png

Accepted flags

  • -i/--import - Resolve all imports automatically by fetching the right files.
  • -c/--content - Allow passing in file contents as arguments instead of file paths.

dependencies

The dependencies command outputs the c3-linearization of a given contract's inheritance graph. Contracts will be listed starting with most-derived, ie. if the same function is defined in more than one contract, the solidity compiler will use the definition in whichever contract is listed first.

surya dependencies Exchange Exchange.sol

Accepted flags

  • -i/--import - Resolve all imports automatically by fetching the right files.
  • -c/--content - Allow passing in file contents as arguments instead of file paths.

parse

The parse command outputs a treefied AST object coming from the parser.

Accepted flags

  • -j/--json - Return a JSON object instead of a treefied object.
surya parse MyContract.sol

mdreport

The mdreport command creates a Markdown description report with tables comprising information about the system's files, contracts and their functions. Much like describe but outputting to a nicely formatted Markdown file.

surya mdreport report_outfile.md MyContract.sol

License

GPL-3.0

Kudos

Created by @federicobond extended by @GNSPS

surya's People

Contributors

1cbyc avatar ana0 avatar arobelix avatar dependabot[bot] avatar federicobond avatar gnsps avatar hacker-dom avatar hdsfade avatar jchittoda avatar matthewethantam avatar maurelian avatar pierce403 avatar rhynorater avatar smarx avatar speakerwiggin avatar tintinweb avatar vittominacori avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

surya's Issues

lint

jshint throws a gazillion warnings :) most of them just being missing semicolons. still worth fixing.

Support running on Truffle projects contract folder

Implement a global flag, accepted on every command, that runs the command on every contract inside Truffle's contract folder (if ran from the root folder).

The point is to avoid the whole find contracts -name "*.sol" -print | xargs surya [sub-command] pattern and substitute it for surya -t [sub-command]

Cannot read property 'mul' of undefined

To repro:

  1. git clone https://github.com/arcadeum/niftyswap
  2. cd niftyswap
  3. surya ftrace -i NiftyswapExchange::_baseToToken all contracts/exchange/NiftyswapExchange.sol

Output is:

/Users/primary/.nvm/versions/node/v10.18.0/lib/node_modules/surya/node_modules/yargs/yargs.js:1109
      else throw err
           ^

TypeError: Cannot read property 'mul' of undefined
    at constructCallTree (/Users/primary/.nvm/versions/node/v10.18.0/lib/node_modules/surya/lib/ftrace.js:604:49)
    at /Users/primary/.nvm/versions/node/v10.18.0/lib/node_modules/surya/lib/ftrace.js:656:13
    at Array.forEach (<anonymous>)
    at constructCallTree (/Users/primary/.nvm/versions/node/v10.18.0/lib/node_modules/surya/lib/ftrace.js:635:34)
    at /Users/primary/.nvm/versions/node/v10.18.0/lib/node_modules/surya/lib/ftrace.js:656:13
    at Array.forEach (<anonymous>)
    at constructCallTree (/Users/primary/.nvm/versions/node/v10.18.0/lib/node_modules/surya/lib/ftrace.js:635:34)
    at ftrace (/Users/primary/.nvm/versions/node/v10.18.0/lib/node_modules/surya/lib/ftrace.js:237:3)
    at Object.require.usage.command.command.command.command.command.command.command [as handler] (/Users/primary/.nvm/versions/node/v10.18.0/lib/node_modules/surya/bin/surya:157:17)
    at Object.runCommand (/Users/primary/.nvm/versions/node/v10.18.0/lib/node_modules/surya/node_modules/yargs/lib/command.js:235:44)

I tested all other surya commands and they work fine on this contract.

[Windows] No such file or directory

Hi,

I'm trying the following command on Windows:
surya describe *.sol

But I get this error:
Error: ENOENT: no such file or directory, open 'XXXXXXXX\*.sol'

It seems that the wildcard is not recognized on Windows and that it tries to find a file named *.sol.

EDIT:
I also try giving to the command a directory but I get Error: EISDIR: illegal operation on a directory, read.

Proposal of draggable report

Hi

This is just a proposal.
I developed same kind of tool to visualize contracts.

https://github.com/tagomaru/solidity-visualizer
https://www.npmjs.com/package/solidity-visualizer

solidity-visualizer generates reports for inheritance and use relations among contracts like surya, however
this report contracts can be draggable unlike dot file.

And this is compatible to truffle project by just one command.

If you think these characteristics are advantages, I can add these to surya.

Thx!

Include compiler versions in output

I don't know what command this belongs under, but it would be helpful for auditing to identify mismatches in compiler versions. ie.

A file with pragma solidity 0.4.24 and another with pragma solidity 0.4.10^.

Support Solidity's library syntax

Related to #6 & #31

The using .. for syntax is currently not considered in any of the commands (pertinent ones being graph and ftrace) and this makes it so that member accesses in elementary types (like when using SafeMath for uint256) look like external calls to unspecified contracts.

While this is was not too bad in graph until now, the problem is even bigger in ftrace, that crashes on some instances of this problem.

Goals:

  • Build the functionality to be easily applied cross-command.
  • Avoid a pitfall: make sure that member addresses being analyzed this way do not span across multiple contracts even if in the same file.

Bonus points:

  • Even though there is absolutely no test framework, if you start creating tests for these I'll send you LOVE tokens โค๏ธ ๐Ÿ˜‚
  • If you already prepare this to accommodate changes for solc's versions ^0.5.0 changes to structs/library syntax I'll send you some of my ETH. ๐Ÿ˜„ (v. ethereum/solidity#4029)

Graphviz interpreter fails on syntax error?

this line is typical of other lines in graphviz generated files that begin with subgraph,

subgraph "cluster[{"type":"MemberAccess","expression":{"type":"Identifier","name":"pending"},"memberName":"to"}]"

except that the naming convention isn't maintained.

instead of:

subgraph "clusterArrays" {
graph [...]
}

subgraph "clusterAddress" {
graph [...]
}

subgraph "clusterReentrancyGuard" {
graph [...]
}

we have

subgraph "cluster[{"type":"MemberAccess","expression":{"type":"Identifier","name":"pending"},"memberName":"to"}]" {
graph [...]
}

so it violates the observed naming convention in this autogenerated file, which returns a syntax error when run through dot -Tpng

ftrace address.transfer()/address.send() Error

the address.transfer() and address.send() builtin solidity functions seem to be not recognized by the ftrace command.

Contract

pragma solidity ^0.4.18;

contract Test {
  function _transfer(address _to, uint256 _amount) public {
    _to.transfer(_amount);
  }
  function _send(address _to, uint256 _amount) public {
    _to.send(_amount);
  }
  function _call_value(address _to, uint256 _amount) public {
    _to.call.value(_amount)();
  }
}

Actual result

running surya ftrace on this file gives

command output errors
surya Test::_transfer all Test.sol TypeError: Cannot read property 'transfer' of undefined
surya Test::_send all Test.sol TypeError: Cannot read property 'send' of undefined
surya Test::_call_value all Test.sol no errors

error output stack trace is in both cases:

at constructCallTree (/usr/local/lib/node_modules/surya/lib/ftrace.js:397:49)
at /usr/local/lib/node_modules/surya/lib/ftrace.js:441:11
at Array.forEach (<anonymous>)
at constructCallTree (/usr/local/lib/node_modules/surya/lib/ftrace.js:428:34)
at ftrace (/usr/local/lib/node_modules/surya/lib/ftrace.js:450:3)

Expected result

No errors output

[EPIC] Generate a complete summary of a contract

This is a bit of an epic, but the more I use surya, the more I want this.

I want to generate a summary of the resulting child contract after inheritance, including storage, and all functions.

The output would be something like this:

Exchange

    address public currentContextAddress;
    mapping (bytes4 => IAssetProxy) public assetProxies;
    mapping (bytes32 => mapping (address => bool)) public preSigned;
   ...

    MixinWrapperFunctions::fillOrKillOrder() public
    MixinAssets::withdrawERC20() external
...

   etc.

But prettier. This feature would combine elements of ftrace and dependencies, and require new storage parsing, but it would be awesome.

ftrace crashes when using abi.encode

If the contract uses abi.encode, abi.encodePacked (and probably any abi method), surya ftrace crashes:

...>: npx surya ftrace Test::test1 all Test.sol 
Cannot read property 'encodePacked' of undefined
...>: npx surya ftrace Test::test2 all Test.sol 
Cannot read property 'encode' of undefined

A simple reproduction contract:

pragma solidity ^0.5.3;

contract Test {
    function test1() external returns (bytes) {
        return abi.encodePacked(uint16(1), bytes32('test'));
    }
    function test2() external returns (bytes) {
        return abi.encode(uint16(1), bytes32('test'));
    }
}

Using ___ for ___ not parsed properly

The method call syntax incorrectly interprets the value being operated on as an external contract.

contract Example
{
    using SafeMath for uint256;

    // The total supply of tokens
    uint256 private totSupply; /* There is a separate getter below. No idea why people do that.  */

    function foo() {
        totSupply = totSupply.add(amount);
    }
}

Surya graph output:

misattrib

Create a comprehensive test suite

We necessarily have to create thorough tests.

So far I think our best option would be to use mocha-sinon and spy on console.logs but any help is greatly appreciated.

Has the library issue been resolved yet?

Has the library issue in ftrace been fixed? I have the same issue. When library safemath is present in a contract,
"TypeError: Can not read property 'sub' of undefined"

how to add all contracts to analysis

In the readme.md, the line for making a graphviz diagram of all contracts is

surya graph contracts/**/*.sol | dot -Tpng > MyContract.png

however I do not understand what the "**" syntax is. It doesnt run in my version of bash, and I cant google my way out of it.

It seems that this output would show the graph for all the interacting .sol files? but I also dont know if that is what is supposed to happen.. certainly the syntax would imply that.

}Sorry if this is an ultra noob question, but Ive got 25 years of linux sysadmin and development, and I cannot see how to unpick the question without asking!

thanks

Support receive function

Currently it doesn't support the receive function introduced in Solidity 0.6.0 as described here.

/home/chris/.npm-global/lib/node_modules/surya/node_modules/yargs/yargs.js:1109
      else throw err
           ^
ParserError: mismatched input '(' expecting {'from', 'calldata', 'constant', 'internal', 'private', 'public', Identifier} (79:9)
...

Print legends

context

I'd like to make the tool output very expressive.

ie. for each function in a contract, you should be able to see it's properties for visibility, payability, and mutability.

This would ideally be done with colors, and expressive symbols.

Suggestion

for the describe, graph, and inheritance commands, add a --legend option, which would output some simple example contract to demonstrate the meaning of all the colors and symbols.

Surya doesn't seem to support some 0.6.x Solidity features

Consider this contract:

pragma solidity >=0.6.0;

abstract contract Abstract {}

Running surya generates this error

$ surya describe ./contract.sol

/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/yargs/yargs.js:1133
      else throw err
           ^
ParserError: extraneous input 'abstract' expecting {<EOF>, 'pragma', 'import', 'contract', 'interface', 'library'} (4:0)
    at Object.parse (/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/solidity-parser-antlr/dist/index.js:79:11)
    at describe (/home/daniel/.npm-packages/lib/node_modules/surya/lib/describe.js:21:24)
    at Object.require.usage.command [as handler] (/home/daniel/.npm-packages/lib/node_modules/surya/bin/surya:14:5)
    at Object.runCommand (/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/yargs/lib/command.js:235:44)
    at Object.parseArgs [as _parseArgs] (/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/yargs/yargs.js:1046:30)
    at Object.get [as argv] (/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/yargs/yargs.js:989:21)
    at Object.<anonymous> (/home/daniel/.npm-packages/lib/node_modules/surya/bin/surya:101:3)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)

Similarly with this contract

pragma solidity >=0.6.0;


contract Immutable {
    uint public immutable ImmutableUint;
}

We get another error

$ surya describe ./contract.sol

/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/yargs/yargs.js:1133
      else throw err
           ^
ParserError: extraneous input 'ImmutableUint' expecting {';', '='} (5:26)
    at Object.parse (/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/solidity-parser-antlr/dist/index.js:79:11)
    at describe (/home/daniel/.npm-packages/lib/node_modules/surya/lib/describe.js:21:24)
    at Object.require.usage.command [as handler] (/home/daniel/.npm-packages/lib/node_modules/surya/bin/surya:14:5)
    at Object.runCommand (/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/yargs/lib/command.js:235:44)
    at Object.parseArgs [as _parseArgs] (/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/yargs/yargs.js:1046:30)
    at Object.get [as argv] (/home/daniel/.npm-packages/lib/node_modules/surya/node_modules/yargs/yargs.js:989:21)
    at Object.<anonymous> (/home/daniel/.npm-packages/lib/node_modules/surya/bin/surya:101:3)
    at Module._compile (internal/modules/cjs/loader.js:778:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
    at Module.load (internal/modules/cjs/loader.js:653:32)

It seems that support for 0.6.x is not included.

Unified Input/Output Rules

Right now Surya has some mixed input/output rules. I propose unifying them to a common format.

For output, I suggest sending everything to stdout. For input, we should extend the rules Surya already has. Here is the current output from surya --help:

surya <cmd> [args]

Commands:
  surya describe <files..>                  show file contracts structure.
  surya graph <files..>                     generate graph of contract function
                                            calls.
  surya inheritance <files..>               generate graph of contract
                                            inheritance tree.
  surya dependencies <target_contract>      output a linearized list of smart
  <files..>                                 contract dependencies (linerized
                                            inherited parents).
  surya parse <file>                        output AST generated by the parser
                                            for the specified file in a textual
                                            tree format.
  surya ftrace <function_identifier>        output the selected function call
  <function_visibility_restrictor>          trace in a textual tree format.
  <files..>                                 External calls are marked in
                                            `orange` and internal calls are
                                            `uncolored`.
  surya mdreport <outfile> <infiles..>      output a markdown file

Options:
  -h, --help     Show help                                             [boolean]
  -v, --version  Show version number                                   [boolean]

For a new format I would suggest we use the following convention across all of Surya's operations
input
surya <cmd> infile1.sol infile2.sol ...

output
stdout

Parser Error

surya parse  ../my_audits/mc/**/*.sol

/usr/local/lib/node_modules/surya/node_modules/yargs/yargs.js:1133
      else throw err
           ^
Error
    at new ParserError (/usr/local/lib/node_modules/surya/node_modules/solidity-parser-antlr/dist/index.js:25:16)
    at Object.parse (/usr/local/lib/node_modules/surya/node_modules/solidity-parser-antlr/dist/index.js:71:11)
    at parse (/usr/local/lib/node_modules/surya/lib/parse.js:13:22)
    at Object.require.usage.command.command.command.command.command [as handler] (/usr/local/lib/node_modules/surya/bin/surya:54:5)
    at Object.runCommand (/usr/local/lib/node_modules/surya/node_modules/yargs/lib/command.js:235:44)
    at Object.parseArgs [as _parseArgs] (/usr/local/lib/node_modules/surya/node_modules/yargs/yargs.js:1046:30)
    at Object.get [as argv] (/usr/local/lib/node_modules/surya/node_modules/yargs/yargs.js:989:21)
    at Object.<anonymous> (/usr/local/lib/node_modules/surya/bin/surya:91:3)
    at Module._compile (module.js:652:30)
    at Object.Module._extensions..js (module.js:663:10)

Expected result:
A parse tree of this rudimentary Metacoin repo from truffle unbox (but I get the same error also on more complex contracts.)

Actual Result:
A parser error.

This also occurs with the rest of Surya's functions, except for surya describe which sort of works (it prints normal output at first), and then throws the same type of error/stack trace at the end.

What I've Tried:

apt update
apt upgrade
npm install -g yargs
npm uninstall -g surya
npm install -g surya
npm install -g npm
npm install -g solidity-parser-antlr 
npm install -g solc 
npm install -g solidity 
npm install -g ethereum

All above updates/installs/uninstalls completed successfully.

  • This error occurs:

    • on my desktop PC, running Linux 4.15.0-39 | Ubuntu 18.04 | x86_64.
  • This error does not occur:

    • on my laptop PC, running Linux 4.15.0-39 | Ubuntu 18.04 | x86_64.
    • on my Android device, running Surya through termux.

The yargs.js line in the stack trace points to this snippet:

1115   โ”‚       // Check if any of the options to skip validation were provided
1116   โ”‚       if (!skipValidation && options.skipValidation.length > 0) {
1117   โ”‚         skipValidation = Object.keys(argv).some(key => options.skipValidation.indexOf(key) >= 0 && argv[key] === true)
1118   โ”‚       }
1119   โ”‚ 
1120   โ”‚       // If the help or version options where used and exitProcess is false,
1121   โ”‚       // or if explicitly skipped, we won't run validations.
1122   โ”‚       if (!skipValidation) {
1123   โ”‚         if (parsed.error) throw new YError(parsed.error.message)
1124   โ”‚ 
1125   โ”‚         // if we're executed via bash completion, don't
1126   โ”‚         // bother with validation.
1127   โ”‚         if (!argv[completion.completionKey]) {
1124   โ”‚ 
1125   โ”‚         // if we're executed via bash completion, don't
1126   โ”‚         // bother with validation.
1127   โ”‚         if (!argv[completion.completionKey]) {
1128   โ”‚           self._runValidation(argv, aliases, {}, parsed.error)
1129   โ”‚         }
1130   โ”‚       }
1131   โ”‚     } catch (err) {
1132   โ”‚       if (err instanceof YError) usage.fail(err.message, err)
1133   โ”‚       else throw err
1134   โ”‚     }

The solidity-parser-antlr line in the stack trace points to this snippet:

  19   โ”‚ function ParserError(args) {
  20   โ”‚   this.name = 'ParserError';
  21   โ”‚   this.message = args.errors.map(function (e) {
  22   โ”‚     return e.message;
  23   โ”‚   }).join('. ');
  24   โ”‚   this.errors = args.errors;
  25   โ”‚   this.stack = new Error().stack;
  26   โ”‚ }

Describe a derived contract

Building on #26, create a complete model of the final derived contract.
A side effect of this, will likely be that we need to track all import paths, and consequently, indicating a single contract in a single file should be sufficient to identify and model all imported contracts.

Improvement: describe output could be self-explanatory

Hi, I want to propose a little improvement.

I never remember what surya describe's # and ($) mean, so I have to open this repo every time I use surya.

Adding a small explanation in the output would be helpful. Alternatively, the symbols can be replaced with words.

Compute functions' selectors

Build the capability to compute a function's selector in order to integrate these in the mdreport command output

Setup CI

We need to setup CircleCI and get a proper release flow

Add modifiers to the functionProfiles

Part of #26.

Modifiers should be tracked in functionProfiles in a fashion similar to visibility specifiers.
They should also be tracked at the same level as functionProfiles themselves, in case they access storage.

ftrace mislabels the inherited source contract of called functions

image

This was generated with surya ftrace MixinExchangeCore::fillOrder all protocol/Exchange/*.sol from within this directory:
https://github.com/0xProject/0x-monorepo/tree/development/packages/contracts/src/2.0.0

All functions in the output are labelled as MixinExchangeCore, although many of the called functions are defined in other Mixins.

What I know

For debugging, I focused on the isValidSiganture function, which is called here in MixinExchangeCore, and defined in MixinSignatureValidator.

I would expect it parserHelpers.isRegularFunctionCall(node) to return true on it, but none of the if/else cases in the FunctionDefinition visitor are matched. If I add console.log('do nothing block', contractName, functionName) to the final else, there are quite a few functions printed to the log. https://github.com/ConsenSys/surya/blob/master/src/ftrace.js#L247

Update Lore With Some Cool Details

It would be nice to have a sentence or two in the README elucidating/dramatizing the importance of the sun god to smart contract security, so that the name doesn't seem random.

From Wikipedia:

The oldest surviving Vedic hymns, such as the hymn 1.115 of the Rigveda, mention Sลซrya with particular reverence for the "rising sunโ€ and its symbolism as dispeller of darkness, one who empowers knowledge, the good and all life.

I think this can be incorporated to the description somehow, for example:

  • Surya as
    • Dispeller of darkness -- Looks deep inside Smart Contracts to illuminate their true inner workings.
    • Empowerer of knowledge -- Before something is illumined, knowledge is impossible. Illumination makes knowledge about something possible. Surya illuminates smart contracts, therefore Surya empowers knowledge about them.
    • Empowerer of the good -- The good for Diligence is to give people safe smart contracts to use. Since Surya helps us create safe smart contracts, then Surya empowers the good.
    • Empowerer of all life -- All life includes life on this earth that can use smart contracts to form better and more solid agreements, then Surya empowers all life.

Include option to exclude test / default directories

Files and directories that should (usually) be excluded by default. Consider adding a switch to include these in Surya's analysis if desired.

Files
Migrations.sol
Test___.sol
test___.sol

Directories
Tests
Test
tests
test
Mocks
Mock
mocks
mock

Feature Request: CFG of Contracts only

A nice way to get a feel for the system would be to simplify the current call graph diagram, so that it shows calls between contracts, without showing the functions.

This would likely look a bit more like the inheritance graph, but showing calls instead of inheritance.

Keep getting "The contract MyContract contract is not present in the codebase."

Been having this problem on any contract I try to use it on, explaining it below with a sample

contract MyContractFile.sol

contract MyContract {
  function someFunction() public view {
    // do something
  }
}

invocation

while being in the directory where MyContractFile.sol is located

surya ftrace "MyContract::someFunction" all MyContractFile.sol

result

The contract MyContract contract is not present in the codebase.

Match color of graph functions to describe output

It would be really helpful if functions in graph were colored by visibility, and if the coloring matched the describe color scheme.

image

That would make it easy to see the entry points, and the describe command would serve as a legend.

Improvements to the `dependencies` command

From @federicobond on twitter:

Would be awesome to show the inheritance subgraph for every method (showing only those parent contracts where the overridden method is defined). Also distinguish overridden completely vs extended using super.

I agree, as identifying function overrides is the real motivation for this feature. Maybe that would look like

Child
  โ†– Parent1
      - foo() overrides Parent2::foo()
  โ†– Parent2
      - foo() overridden
      - bar() extends Parent3:bar()
  โ†– Parent3
      - bar() extended by Parent2
  โ†– Parent4
  โ†– Parent5

Unless developers are doing some really crazy stuff with function overriding, there shouldn't be too much additional output to parse mentally.

Cannot handle payable address

Running mdreport on a contract with a payable address crashes.

$ surya mdreport s.md a.sol

/home/daniel/.npm-global/lib/node_modules/surya/node_modules/yargs/yargs.js:1133
      else throw err
           ^
Error
    at new ParserError (/home/daniel/.npm-global/lib/node_modules/surya/node_modules/solidity-parser-antlr/dist/index.js:25:16)
    at Object.parse (/home/daniel/.npm-global/lib/node_modules/surya/node_modules/solidity-parser-antlr/dist/index.js:71:11)
    at mdreport (/home/daniel/.npm-global/lib/node_modules/surya/lib/mdreport.js:33:24)
    at Object.require.usage.command.command.command.command.command.command.command [as handler] (/home/daniel/.npm-global/lib/node_modules/surya/bin/surya:85:5)
    at Object.runCommand (/home/daniel/.npm-global/lib/node_modules/surya/node_modules/yargs/lib/command.js:235:44)
    at Object.parseArgs [as _parseArgs] (/home/daniel/.npm-global/lib/node_modules/surya/node_modules/yargs/yargs.js:1046:30)
    at Object.get [as argv] (/home/daniel/.npm-global/lib/node_modules/surya/node_modules/yargs/yargs.js:989:21)
    at Object.<anonymous> (/home/daniel/.npm-global/lib/node_modules/surya/bin/surya:91:3)
    at Module._compile (internal/modules/cjs/loader.js:734:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:745:10)

Contract

pragma solidity ^0.5.0;

contract C {
    function a(address payable _addr) external {}
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.