Thanks... I'll take a look at it.
Thomas Reinke wrote:
> 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
