Re: [RFC][patch] XML structured script output (evaluation of nse-structured3 patch)

[David Fifield <david () bamsoftware com>]

On Sat, Jun 30, 2012 at 03:54:45AM -0400, Patrick Donnelly wrote:
> On Fri, Jun 29, 2012 at 5:04 PM, Rob Nicholls <robert () robnicholls co uk> wrote:
> > My vote would probably be for a single representation, which
> > automatically generates XML for all scripts (in a consistent manner, so we
> > don't have to worry too much about making it "backwards-compatible", and
> > preventing any opt-in or opt-out problems),
>
> I personally would like to see that scripts produce some ScriptOutput
> object which is returned to NSE. This object can be used to produce
> XML/normal output. Said differently, let the script encode the output
> as a regular Lua object (table) rather than as a string. Encoding the
> script output as a string seems like unnecessary complication to me.

This is the plan. Scripts return a table from which output formats are
derived.

> A regular string returned to NSE would be coerced into a ScriptOutput
> using some type of sane conversion.

The conversion is going to be "if you return only a string, you don't
get any structured output." What's shown on the screen goes into
script@output as always, but there won't be any child elements of
script.

Daniel had a patch (http://seclists.org/nmap-dev/2012/q2/375) that
attempted to automatically scrape structured output from what was given
to stdnse.format_output
(https://secwiki.org/w/Nmap/Structured_Script_Output#Proposal_alpha). I
rejected that idea, because the output was not really any more
"structured" than normal output. (A program could scrape script@output
for colons and recover basically the same information.) I particularly
didn't want to codify "structured" output with key names like "Public
Key type" and values like "organizationName=Equifax/countryName=US"
(which should be further broken down). This would make it even more
painful to change to something more useful in the future, if XML
processing scripts came to depend on such output.

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