Mirage: a sourceful of secrets
Myself in Summer 2011 I drow the Mirage path for the next months thanks to… well, thanks to venerable Flex and Bison tools.
From latest post, in English this sentence
"L'ultimo punto vuol dire, la progressiva dismissione del progetto Orizon,
che vuol dire che se questo laboratorio avrà successo magari ci sarà un
Owasp Mirage al posto del suo predecessore"
sounds that if mirage will be a successful laboratory project, than it will replace Orizon definitely.
Let’s talk a bit further about what I’ve done this Summer.
First of all, GNU autotools. I used autotools from GNU to build a package that everyone can
"configure; make; make install"
I discovered that this approach is hard to follow if the filesystem hierarchy is complex.
I have to make some dependency check so the make command will know also about the shared libraries it has to build.
Second point, shared libraries. My idea about mirage architecture is to be plugin based. This approach leads the core to be decoupled from the more specialized subsystems. I started implementing this via shared libraries but I didn’t find a common data structure to hold data from main to libraries helper. YET.
Now I started hanging around some very basic SAST technique: code crawling
Breaking down the source code in tokens is straightforward easy with flex, and libcrawler is in place doing this.
The idea is to placing in a database (either sql or nosql) the dangerous keywords and look the tokens for them. No more, no less.
This one should help me understand how good is the architectural approach I choose and I easy is mirage to develop this way.