Re: NSE argument table syntax

[David Fifield <david () bamsoftware com>]

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