Re: NSE argument table syntax

[Joao Correa <joao () livewire com br>]

Hi David,

Thanks for the answer. I've discussed it a little with Patrick and we
also agreed that it is not a great deal.

I was just worried about making a function to keep it simpler for the
future scripts. Do we expect that the backwards compatibility still
works on these scripts to come? If so, it would be nice to have such
function.

I agree that the patch is not working, I've also found some other
situations where it won't fix the problem. Sorry for not having
updated it earlier.

There are 4 scripts that use table arguments and it is not hard to
make the manual checkings on them. The problem is just that it will be
a recurrent problem for the future, as mentioned.

Also, there is one more problem. Using the new syntax requires
programmers to use nmap.registry.args['table.arg'] instead of
nmap.registry.args.table.arg. I don't know if everyone agrees, but I
think that it can make the code a little dirtier.

It seems that it is good exchange, since it will make script args much
more user-friendly, at cost of making it a little less
programmer-friendly, hehe. But, everyone agrees?

Thank you
Joao Correa

On Mon, Jun 22, 2009 at 10:18 PM, David Fifield<david () bamsoftware com> wrote:
> On Mon, Jun 22, 2009 at 07:04:27PM -0300, Joao Correa wrote:
> > On my last meeting with Fyodor, David and Patrick we discussed about a
> > new syntax to use script argument tables. This new syntax would be
> > much simpler to use since,
> >
> > nmap ... --script-args=httpproxy={url=scanme.nmap.org,pattern=xxx}
> >
> > would became:
> >
> > nmap ... --script-args=httpproxy.url=scanme.nmap.org,httpproxy.pattern=xxx
> >
> > This new syntax is already supported by NSE, the only problem is that
> > doing the old way you would have one extra indirection, the table
> > httpproxy would be a table inside nmap.registry.args. Using the new
> > syntax this indirection does not exist, and httpproxy.url (for
> > example) is the index inside the table nmap.registry.args.
> >
> > This turns out to be a problem when trying to keep backwards
> > compatibility, because it would be correct for scripts to accept both
> > syntaxes. Scripts must have a way to deal with both and it can make
> > them more complex.
>
> Hello João. My first reaction is that it's better to just do explicit
> backwards-compatible checking in every script that needs it. There are
> not that many scripts that use script arguments, and some of them
> already work more or less according to the new proposed standard (I can
> think of whois and smb-*).
>
> Weighing the benefits and costs of doing manual checking in each script
> versus making it a separate function, manual checking has some code
> duplication but will be very clear to a reader as to what it's doing,
> while having a separate function will let the code be slightly shorter
> but will be more opaque and require the reader to look in another file.
> Plus, if the old table syntax is to be deprecated, it will be harder to
> do that if new scripts start to use the proposed parse_table_args.
>
> How many scripts would need to be modified? I think there are fewer than
> five. If it's more than that I might change my opinion.
>
> > I've written a function and appended to stdnse lib. This function
> > transforms arguments with the new syntax in arguments with the old
> > one. The problem is that this function must be called explicitly
> > inside the scripts, since it relies on knowing the table and argument
> > names. I'm not sure that it is the best way to do so, perhaps we could
> > do something similar every time a script is executed, avoiding the
> > explicit call. Any suggestions?
> >
> > Using the function is simple, you just need to set a table with
> > arguments names and call:
> >
> > args = {"url","pattern"}
> > parse_table_args{"proxy",args}
>
> This function wouldn't work in this example, because the http-open-proxy
> script currently uses a table called "openproxy", not "proxy". (By the
> way, I think I was the one to suggest to suggest "proxy" instead of
> "openproxy" in our meeting, but I take it back. proxy.url sounds as if
> it's the URL of the proxy itself, not the URL of the web page to try to
> retrieve through the proxy.)
>
> David Fifield
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org

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