Ron, Thanks for the response. Since it's XML, the application wouldn't care where the <Targets> falls as long as the hierarchy is the same. And since I'm writing the application myself, I'll make SURE it doesn't care.
My concern was with EXTRA XML nodes in the .nessus file; that is, adding a <Directives> node or a <Controls> node or a <Routing> node, etc. Right now, the nessus client ignores those sections and leaves them untouched, which is great for me because I can use the .nessus file as a sort of "in-band," one-stop-shopping repository for component communications. This works very well for the SOA nature of what I'm implementing. My hope is that the nessus client will continue to ignore these extra nodes and continue to pass them along untouched. I would not expect you to add a QA step for lil' old me and my one-off applications... just looking for a non-official guess as to future directions. John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Gula Sent: Wednesday, July 23, 2008 6:32 AM To: [email protected] Subject: Re: DOT-NESSUS FILE Hi John, I haven't looked into this nor have I asked anyone at Tenable to look into it. You may be taking advantage of some implementation issues and if an application that processes the .nessus file is expecting to run into the <Targets> element right after the <NessusClientData>, they could have errors. I don't forsee any coding changes to the Nessus Client that would impact your modifications if you use them locally, but at the same time, we're not adding a QA step that makes sure your modifications aren't broken in the future or modifying the official XSD and file format. Ron Gula Tenable Network Security John Scherff wrote: > My question: will this continue to be the behavior in the future? > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of John Scherff > Sent: Monday, July 21, 2008 6:12 PM > To: [email protected] > Subject: DOT-NESSUS FILE > > > Tenable Team, > > I was pleasantly surprised to find out that extraneous XML is not > stripped out of the dot-nessus file by the scanner. I plan to create > a new node called <Directives> (a sibling to <Policies>) and beneath > that will be configuration items of my own which will be consumed by > post-scan handlers (e.g., scripts that convert and email the scan > results). For example: > > <?xml version="1.0"?> > <NessusClientData> > <Directives> > <Directive> > <name>outputFormats</name> > <value>html;nbe</value> > </Directive> > <Directive> > <name>emailRecipients</name> > <value>[EMAIL PROTECTED],[EMAIL PROTECTED]</value> > </Directive> > <Directive> > <name>attachResults</name> > <value>no</value> > </Directive> > <Directive> > <name>stripInfos</name> > <value>yes</value> > </Directive> > </Directives> > <Targets> > ... > </Targets> > <Policies> > <Policy passwordsType="Linux"> > <policyName/> > <policyComments/> > ... > </NessusClientData> > > My question: Is it by accident or design that unused XML is ignored > and left untouched by the nessus, and will this continue to be the > behavior in the future? > > Thanks, > > John Scherff > Information Security and Storage Manager > 24 Hour Fitness > o: 760-918-4485 > c: 760-351-6946 > e: [EMAIL PROTECTED] > > The code of competence is the only system of morality that's on a gold > standard. -Ayn Rand > _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus _______________________________________________ Nessus mailing list [email protected] http://mail.nessus.org/mailman/listinfo/nessus
