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
Current thread:
- NSE argument table syntax Joao Correa (Jun 22)
- Re: NSE argument table syntax David Fifield (Jun 22)
- Re: NSE argument table syntax Joao Correa (Jun 22)
- Re: NSE argument table syntax Kris Katterjohn (Jun 22)
- Re: NSE argument table syntax David Fifield (Jun 22)
- Re: NSE argument table syntax Joao Correa (Jun 23)
- Re: NSE argument table syntax Joao Correa (Jun 22)
- Re: NSE argument table syntax David Fifield (Jun 22)