On Thursday 12 March 2009 15:52:44 Shawn Duffy wrote: > Are there any plans to enforce some sort of standard format for plugin > information in plugins? I'm currently writing an app that parses the > plugins for information and stores it in a database. The app, once it > reaches a reasonable level of maturity, will be open source and > available to anyone. I find its a very good idea. When do you think that this maturity level would be reached? And which information do you want to include in the db?
> However, in trying to extract information from plugin files, I'm finding > a huge variety of formats for plugin information. For example, plugin > name. There are multiple ways the name may appear in a particular plugin: > Is it possible to parse this using a fairly simple RegEx? Sure. But > since everyone appears to be free to add their info anyway they like, as > long as it is syntactically correct in NASL, you're forced to > continually check new plugins to see if some other contributed script > has come up with an entirely new way to enter the info. I was toying around with libraries to build a dependency and include graph for NVTs. Another idea was to visually represent knowledge base items and insert set_kb and get_kb edges, so that it would be possible to see which plugins access which knowledge base items. Fairly simple regexps worked okay for that task (I got a good number of true results), however you get a resolution problem when variables are involved. I am not sure if that is allowed in nasl, but I guess it should be: english_name = "NastyNameScript"; name["english"] = english_name; And one can imagine much worse scenarios, where strings are concatenated etc. For that reason I would advise to do what Thomas suggested: Either use * a "fake"- client or * the clients plugin-cache (easy to parse). Another solution would be to use the nasl standalone interpreter (openvas-libnasl/nasl/nasl.c) or some parts of the server component. It is my favorite solution, because of four reasons * I was interested in more "deep" information that is not included in the caches - like includes, maybe which message types are sent etc. * One has to touch and clean up the NVT representation in code :) . * You would not have to worry about upcoming changes to the NASL syntax. * Probably it would be slightly easier to extract the descriptions etc for languages other than english. enjoy felix > So, are there any plans to come up with a basic "style guide" for > plugins? And reject any that aren't in the specific format? It would > be nice to know that script_name, for example, will _always_ be: > > name["english"] = > name["francais"] = > > and so on. I think in the long run this will make OpenVAS that much > more extensible and scalable. I'd even volunteer to help come up with > the guidelines if necessary. Thoughts and criticisms welcome... > > Thanks, > Shawn > > _______________________________________________ > Openvas-plugins mailing list > [email protected] > http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins -- Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/ PGP Key: 39DE0100 Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-plugins mailing list [email protected] http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
