If you are looking at extracting information such as category, ids,
etc, out of the script, you might want to consider checking the
OTP protocol. It's not very complicated to connect to the server
and send a syntactically correct connection request (uid/password,etc)
to the server, after which it immediately dumps to you all the
information available it has on each script, one line per script.
Thomas
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.
>
> 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:
>
> script_name("Actual name of script");
> script_name(english:"Actual name of script");
> script_name(english:name["english"]);
> name["english"] = "Actual name of script";
> name["english"] =
> "Actual name of script";
>
> The script category is another example. I thought the standard format was:
>
> script_category(XXXXXX);
>
> Until I saw:
>
> script_summary(english:"XXXXXX"); script_category(XXXXXXXXXX);
>
> 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.
>
> 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
>
_______________________________________________
Openvas-plugins mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
