Re: [PATCH] Add --dtd and --webdtd for <!DOCTYPE ...> with -oX

[Kris Katterjohn <katterjohn () gmail com>]

William McVey wrote:
> On Tue, 2007-01-23 at 01:47 +0000, Brandon Enright wrote:
> > Attached is a patch against Subversion that adds '--dtd' and
> > '--webdtd' options to allow Nmap to print the <!DOCTYPE nmaprun SYSTEM
> > "..."> element for validating parsers to use.
> >
> > Rather than change existing -oX output and possibly break some
> > parsers, the default is still not to print the <!DOCTYPE ...> element.
>
> The only reason an XML parser should fail due to a DOCTYPE definition is
> if it is a validating parser. With no DOCTYPE defined previously, I find
> it highly unlikely that the -oX output is being handled by a validating
> parser without some level of preprocessing. Even if it would cause some
> breakage in some corner case parsers (perhaps custom string based
> parsers that are naively expect all nodes within <angle brackets> to be
> closed); the format of -oX is *XML* and not having a DOCTYPE is more of
> a bug than a feature.
>
> >  If '--dtd <path>' is used, XML output will contain a reference to the
> > DTD specified in <path>.  I've also added the short-hand '--webdtd'
> > which outputs <!DOCTYPE nmaprun SYSTEM
> > "http://insecure.org/nmap/data/nmap.dtd";>.
>
> I suggest removing the --webdtd option and just making that the default.
> The doctype should include a version number though so that incompatible
> versions of the -oX output can exist in the wild at the same time. The
> overhead for versioning the output format is fairly negligible and will
> allow the XML format to evolve gracefully (just change a #define
> pointing to the new XML format URL and you don't have to worry.
>
> I'm not a huge fan of the --dtd commandline option allowing end users to
> override the SYSTEM path. I'm not dead set against either, but I'm
> particularly concerned that users not up on their XML technologies will
> start specifying this as a simple path to the DTD on their local system;
> not realizing that:
>       * if it is a full pathname then the document likely will no longer
>         be portable off that host
>       * if specified with a relative pathname, the doc now requires the
>         DTD to follow the XML output format
>       * the system identifier is not a path, but a URI (thus subject to
>         the quoting rules specified in RFC 3986 Section 2)
> The option does provide a convenient facility to someone who is familiar
> with XML to keep validation from having to reach out to the net;
> however, since it's is only a 6 line XSL script (or a 1 line perl
> script) to replace the SYSTEM doctype, I'm not sure the convenience is
> worth an invocation specific option.

I'm not trying to be rude, but I just don't get what you're saying. If a
user messes with it, they are *messing* with it. I don't think keeping
this option out of Nmap just because somebody might screw it up, by
their own choice, is a good idea.

Of course, I'm not a big XML person and I don't use -oX very often, and
if I do it's only to view it in a browser real quick. So I'm really just
throwing my 2 cents in :)

> Even better than a catalog match on SYSTEM identifier would be a catalog
> match on a PUBLIC identifier. I propose that in addition to the URL
> format listed above, a PUBLIC document declaration be added, resulting
> in a document declaration of the form:
>
>         <!DOCTYPE nmaprun PUBLIC "-//INSECURE.ORG//DTD NMAP V4.0//EN" "http://insecure.org/nmap/data/nmap-v4.0.dtd";>
>         
> Like I said, I'm pretty up in the air whether the system URI should be
> overrideable with an option, but I do feel that the above declaration
> should be added by default on the XML output. An important thing to note
> is that adding this declaration would likely increase the amount of
> traffic to the URL listed as the SYSTEM URI, as anyone who hasn't
> installed an XML catalog entry or otherwise overridden the DTD
> resolution would reach out to insecure.org if the output is run through
> a validating parser.
>
>   -- William

-Kris

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