Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: NSE argument table syntax
From: Joao Correa <joao () livewire com br>
Date: Mon, 22 Jun 2009 22:32:20 -0300

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault