Roadmap

[duaraghav8]

I haven't been in touch with Open Source lately (6 months to be exact), but am back now =) Need to brush up on certain things so I can continue active maintenance of this project. Checklist:

• [x] Know what's the latest in Solidity Language (that hasn't been accounted for in solium)
• [x] Revisit all pieces of this project to refresh memory on how this thing works
• [x] Revisit issues opened so far
• [ ] Check for cross-platform support (make sure solium runs as expected on different Operating systems)
• [x] Revisit development in Consensys' solidity-parser & how far behind is solparse (fork of solidity-parser that I maintain) lagging.
• [x] Prioritise features & patches
• [x] Determine vision & further project roadmap.
• [ ] Beg someone to make a better logo

[maurelian]

I just happened to be swinging by. Great to see you returning to this, and might be able to submit some PRs once you've prioritized the direction.

[duaraghav8]

@maurelian that would be awesome! I'll be writing in more detail about it very soon :D

[maurelian]

So, since I've got your ear, I'd love to see this move in a more eslint direction, similar to #67.

ConsenSys could then add some of our best practices as rules, and possibly expand on them with more of a prescriptive styleguide approach similar to https://github.com/airbnb/javascript

[duaraghav8]

I've been planning to develop this project eslint style for 2 main reasons: First as described in #67 Second being the way eslint allows you to plug in rules and create portable configuration files (http://eslint.org/docs/developer-guide/shareable-configs)

Feross makes a good use of these: https://github.com/feross/standard

all rules implemented for solium will either be part of the core linter or as a "layer on top". Sharable configs are going to make it​ easy for users to use both core & 3rd party-provided rules (and for Devs to implement and distribute their rules easily)

ConsenSys has done a great job with solidity practices, looking forward to your contributions!

Currently, the issue this project faces can be categorised into:

1. Incorrect / Insufficient parsing by solparse
2. Bugs in core rule implementations
3. Architectural flaws (or call them deficiencies), would want to take this project in eslint-direction in order to achieve better architecture.

[federicobond]

Why not use ES6 features and transpile the package code with Babel? Many packages already do that and at the current JavaScript speed, it not unreasonable to think that you will be able to take out the transpiler in a couple of years and have a very clean, modern looking codebase that will work on most devices anyway.

[duaraghav8]

@federicobond agreed, added to TODO

[cgewecke]

@duaraghav8 Not sure if this right issue...but have you seen this: securify.ch?

I looks like some the security issues they're tracking could be detected just by inspecting the AST. Some would need 'symbol table' infrastructure. I fooled around with it a little and they seem to be compiler dependent. The website also can't handle anything that has imports.

[duaraghav8]

@cgewecke just tested it out, but I'm not sure what point you're trying to make here? Are you suggesting we should have a similar functionality (as a layer on top) or something else?

[cgewecke]

Yes - sorry that comment wasn't very clear - I'm wondering about your plans to implement a symbol table in #83 (what will it look like?) because I'm interested in the possibility of developing rules to perform these kinds of checks. Some are very simple though - like seeing if function call arguments are validated before they are used.

[duaraghav8]

ah @cgewecke I haven't started work on this issue (even though this will be the most fun part) since I haven't entirely made up my mind as to which direction the project is headed in.

1. We could either transform it into a full-fledged linting tool (think eslint) so at the end of the day, its still a tool that ensures you're using good smart contract programming practices.

OR

2. We could head toward a tool that ensures contract security (so a dev tool that exclusively and therefore deeply deals with secure contract coding).

The kind of code analysis performed is very different in the above 2. So IMO there's a big difference between ensuring good programming practices and tightening the security of code and that's why we can't build both into solium and we can't be somewhere in the middle or else we make a huge mess.

This is what I want to sort out before we continue with any major changes in solium.

Opinions are welcome from everyone

[maurelian]

Can you elaborate on the second option a bit more?

How would "secure contract coding" be verified in this scenario, if not by ensuring compliance to specific patterns of style and syntax of as it would in the ESLint like scenario? Is there a comparable tool, either in the Solidity,JS or other language ecosystem to help understand?

Also worth noting @federicobond's https://github.com/federicobond/solcheck is pursuing the eslint route.

[cgewecke]

@duaraghav8 That seems fair although like maurelian I'd like to hear more about how you see the distinction. It's reasonable at least to require that security analyses be wholly expressible within a rule and not consume excessive resources / generate false positives, etc.

esLint mostly inspects discrete expressions and spacing but there are some more sophisticated rules in the best practices section - cyclomatic complexity for example.

[federicobond]

Hi! I think Raghav has done a terrific job with Solium so far. I started solcheck because I wanted to explore some other ideas with a faster release cycle, but I see countless opportunities for mutual collaboration in the future. solcheck is more unashamed when it comes to copying the good parts of eslint, and aims to make it as easy as possible to write new rules.

As for the direction of the project, I don't see such a clear cut distinction between ensuring best practices and doing security analysis. It all depends on the specific techniques you want to apply. I will probably take call graph and scope analysis for example, but I won't be doing any symbolic execution in the foreseeable future.

[duaraghav8]

Read this page first: https://www.klocwork.com/products-services/klocwork/application-security

Now let's come to point 2 I talked about. We know what ESlint does. It does a great job of linting but that is the ultimate scope of the project. It only does a small subset of all the things the above link talks about.

By "hardcore security analysis of smart contracts", I meant achieving what the page above talks of (and this link is just an example, there's a lot of content on this and scope for analyzing source code for security is vast).

Achieving these things requires more than an ESlint-like approach. For eg-

1. We'd have to simulate the contract codebase (think sandbox) to watch data flow, memory states, money used, etc. These things tell us what the risks are like when our contracts are actually running in production.

A question like "can a specific user input through web3 cause an infinite loop in my contract?" is very hard to answer in a massive codebase if Solium/Solcheck are just an ESlint for Solidity.

Introducing Symbol table + Data Flow + Control Flow + Resource monitoring + Simulating will effectively mean we're heading toward a security tool and not just a simple linter.

The trouble with the this approach: I'm afraid solium might just end up becoming a bloat and nobody would know the 1 true purpose it is for (think evernote!)

So all I'm trying to say is that a linter, even if security-focused, will only do a subset of jobs a smart contract security tool should be capable of. And since security is what we want to achieve through the linter, why not tranform it into full security software for SCs?

ps- I admit that I'm inexperienced in security (still in college -.-"), so I could be wrong about all this. But I do think strongly about what I'm saying here.

[duaraghav8]

I also just checked out solcheck. I've known Fed to always see things from a different angle so even if at first what he does seems like re-inventing the wheel, it always turns out to be solving a problem very efficiently. I don't doubt that solcheck is going to be fantastic (good luck!). We can certainly collaborate in future. Plus I also admit that I'm not fully inspired by ESlint.

[cgewecke]

@duaraghav8 Thanks! Your analysis is helpful - essentially you're arguing that provisioning the resources necessary for security analysis is specialized and those efforts belong in a dedicated tool? I think that's fair and quite possibly correct as a practical matter alone. I suppose I tend towards Federico's view that the distinction between security and style isn't that clear cut and if a kind of analysis is possible given an infrastructure, well . . . . why not? But talk is cheap. Someone has to write, test and maintain the code. Solium works as advertised which is no small feat.

Thanks for such a thoughtful response to such a vague query, Raghav. I appreciate it.

[duaraghav8]

Thanks to everyone in this thread, v1 is now in Beta. We have moved in the ESLint direction. I'd love to hear any feedback anyone might have :)

npm install -g solium@v1-beta

https://medium.com/solium/introducing-solium-v1-d2bd0a7fbfb