Re: Script selection - Gsoc

[Martin Holst Swende <martin () swende se>]

Just a minor suggestion, if there is going to be work done on script
arguments, wouldn't it be better to try and fix a generic
argument-handling mechanism, so that arguments could be accessed by way
of introspection?
Something like :

args=[foo:"Optional foozing parameter",bar:"If you want  a bar-scan"]

function action(host , port, args)
    foo, bar = unpack(args)
    ...

That way, the engine (or any other library) could read what parameters
are used. It seems to me that some solution like this would be better in
the long run, not least since documentation which is tied that hard to
the actual code will by definition always be up to date.  But perhaps I
am missing something ?

Just my 2 cents...
/Martin


Ron wrote:
> Hey,
>
> I don't think you have to worry too much about arguments that the developer didn't document in the @args fields. At 
> the very most, I'd print a warning of some sort but nothing else. Typically, if there are undocumented arguments, you 
> might not want to advertise them -- they may be pure debugging or something similar. That is, of course, only my 
> opinion. 
>
> One thing to watch out for, though, is requirements. smb-brute.nse, for example, includes unpwdb.lua, which has its 
> own set of (very important!) arguments. So following the tree of requirements is important. 
>
> Ron
>
>
> On Wed, 31 Mar 2010 23:34:46 +0530 kirubakaran S
> <kirubakaran1989 () gmail com> wrote:
>   
> > Hi dev,
> >     I am working great on thinking about script selection
> > interface for Gsoc.  I deduced every script have two type
> > of arguments. One is direct argument which is accessed through
> > the nmap.registry.** - lua table.Another argument is variables in
> > library functions which have default values and it can be changed.
> > To design interface I should know what are all the arguments for a
> > particular script, In this case I can parse @args field in script to
> > know which are all essential arguments. But when script developers
> > forget @args field or if the script uses argument of library
> > variables we cannot enumerate
> >  what are all library variable arguments for this script. Because
> > script developers do not include @args field for arguments of library
> > variables.
> >
> > Example : In pgsqlbrute.nse arguments are
> > 1. pgsql.version
> > 2. pgsql.nossl     ----> type one
> > 3. passdb, unpwdb.passlimit, unpwdb.timelimit, unpwdb.userlimit,
> > userdb
> >      --> type 2 library variables.
> > But script only provides these lines
> > --@args pgsql.nossl If set to 1 or true disables SSL.
> > --@args pgsql.version Force protocol version 2 or 3
> >    while designing interface if I conclude arguments by parsing @
> > args I miss the type2 arguments and user cannot change it!!
> >
> >
> >   To solve this problem , like script.db which stores categories of
> > script. store the names of arguments in script_arguments.db file.
> > And conclude the arguments by searching this file.will this solution
> > for finding out arguments for particular script work out? or can
> > anyone suggest me what is the best way to find out all arguments
> > for script. correct me If I am wrong..
> >
> > Thanks.
> >
> >
> > -- 
> > Kirubakaran.S
> > _______________________________________________
> > Sent through the nmap-dev mailing list
> > http://cgi.insecure.org/mailman/listinfo/nmap-dev
> > Archived at http://seclists.org/nmap-dev/
> >     
>
>
>   

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/