Jan,
Well note for the way to submit patch, i will do next time.
Lets talk about nvt(s) and report, in reply to Matthew :
In fact, using get-nvts to extracts family stuff, what was i was doing
with openvas4.0 and omp2.0.
But it is really a time consuming methods (and more when openvasmd is
charge), with lots of redundancy data not used in the get-nvts-response.
So with openvas5.0, i decide to patch openvasmd to speed up my
xmlresult generate process.
Here is my feelings,
it can only make sense to use get-nvts, if we can have a reduce-report
like Jan propose :
<result>
<subnet/>
<host/>
<port/>
<oid/>
<description/>
</report>
(i was doing that through xsl with openvas4.0)
but there is still a big redundancy info : description field, as today,
plugins output : desc + hostspecificsdata (the description part of the
report).
if plugin only reports hostspecificsdata, the report format
<result>
<subnet/>
<host/>
<port/>
<oid/>
<output/>
</report> become nice, no matter NVTS are in the report or 'get-nvts'.
This is big job, but nice improvments, i must admit that i do not know
(and evaluate) all drawback but i hope i was clear in my explains.
BR
Seb
Le 26/06/2012 17:09, Jan-Oliver Wagner a écrit :
Hello Sebastien,
On Freitag, 22. Juni 2012, Sebastien Aucouturier wrote:
as i need the plugin's Family in each result in report, i do
modification in openvasmd code.
Is it a enhanced that can be put in next release ?
thanks for the submission!
First a general hint:
If you create modification, it is best to use
something like "svn diff > family-in-results.patch"
if you are working with SVN trunk.
Or "svn diff src/manage_sql.c.orig src/manage_sql.c >
family-in-results.patch"
if you used a tarball and of course created a backup file of the
original version.
This way we can easily apply the patch for testing.
("patch < family-in-results.patch")
Now for your patch:
I realize that we have some redundancy already with the <nvt> object
inside results. Adding yet another redundancy won't probably hurt
much,
but doesn't make it better neither.
If yo are about to write a special OMP client, you may already want
to
try using command <get_info> for the details of a NVT.
BTW: I think the "family : ..." is positioned wrong anyway ... ?
I wonder whether we should take this opportunity and create a section
<nvts>
<nvt oid="...">
</nvt>
...
</nvts>
into the report and only have references in the results via the OID.
Then we could add the full NVT information in there always.
It has the disadvantage of obligating clients to de-refernce inside
the XML.
How do people here feel about this?
Best
Jan
src/manage_sql.c : line 13277
/**
* @brief Get the NVT Family from a result iterator.
*
* @param[in] iterator Iterator.
*
* @return The Family of the NVT that produced the result, or NULL
on
error.
*/ family ? family : "",
const char*
result_iterator_nvt_family (iterator_t *iterator)
{
nvti_t *nvti;
if (iterator->done) return NULL;
nvti = nvtis_lookup (nvti_cache, result_iterator_nvt_oid
(iterator));
if (nvti)
return nvti_family (nvti);
return NULL;
}
src/omp.c : line 7105
const char *family = result_iterator_nvt_family(results);
src/omp.c : line 7136
buffer_xml_append_printf
(buffer,
"<subnet>%s</subnet>"
"<host>%s</host>"
"<port>%s</port>"
"<nvt oid=\"%s\">"
"<name>%s</name>"
"<family>%s</family>"
"<cvss_base>%s</cvss_base>"
"<risk_factor>%s</risk_factor>"
"<cve>%s</cve>"
"<bid>%s</bid>"
"<xref>%s</xref>"
"</nvt>"
"<threat>%s</threat>"
"<description>%s</description>",
result_iterator_subnet (results),
result_iterator_host (results),
family ? family : "",
result_iterator_port (results),
result_iterator_nvt_oid (results),
name ? name : "",
cvss_base ? cvss_base : "",
risk_factor ? risk_factor : "",
cve ? cve : "",
bid ? bid : "",
xref ? xref : "",
manage_result_type_threat (result_iterator_type (results)),
descr ? nl_descr : "");
src/manage.h : line 805
const char*
result_iterator_nvt_family (iterator_t *);
--
| Sébastien AUCOUTURIER | Software Design Engineer Lead
| ITrust | 55 rue l'Occitane BP 67303 31673 LABEGE CEDEX
| Email: s.aucoutur...@itrust.fr
| Fixe Sdt. 05.67.34.67.80 | Fax. 09.80.08.37.23
| IT Security Services & SaaS Editor
_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-devel
