-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jan-Oliver
Wagner
Sent: Monday, September 01, 2008 5:40 PM
To: openvas-devel@wald.intevation.org
Subject: Re: [Openvas-devel] OpenVAS plugins standardization
On Montag, 1. September 2008, Vlatko Kosturjak wrote:
> > IMHO information like that a tool was not found to execute
> > should *always* be reported. Because the has requested to execute
> > the respective NVT, he *must* be informed what is the result
> > of the execution. I really hate the way Nessus handles it: don't report
> > anything if nothing is found. I am confident that many many people
> > are scanning networks and think all is OK allthough the
> > server side logs nessusd would show that many plugins
> > failed to execute.
>
> That means if you have e.g. 25000 plugins selected and each of them
> should report it's status(failed/success) and why it failed?
> That would be report of at least 12500 pages!
> well, the printed report should not necessarily contain all of this.
> Even the GUI client should allow it configurable whether
> to manage these information.
By looking at logs and the KB items store, we can make out why a plugin
isn't launched. In any case, it would be better if there's a single location
where we can look through to identify failed instances. Instead of clogging
the reports, can we redirect these to a log and debug file?
> > I guess the daemon will just through an error in the log file as long
> > as the new NASL methods are not implemented.
> > Once the server is extended, we can report it to the client
> > and once this one has extended the information will be available to the
> > user.
> > Hm, as I think about it, we can also simply introduce a better
> > and consistent naming. How about
> > report_hole() (perhaps better report_vulnerability)
> > report_warning()
> > report_note()
> > report_debug()
> > report_log()
> > The old functions can stay for backward compatibility for a while.
> > Just sketched my ideas. What do you think?
>
> > Sounds good. But when we're discussing this report verbosity option.
> > It's important to note and discuss Report paranoia option also as it is
> > tightly connected and should be discussed together (because to clearly
> > differ those two options).
> yes, indeed.
In NASL 'debug' global variable is already there which can be used for this
purpose. So, it can be like
if debug == 1
report_log() # directed to a log file of failed instances
if debug == 2
report_debug() # directed to a debug file
And report_paranoia is used when we are unsure of what we are saying in the
plugin :)
Regards,
Chandra.
_______________________________________________
Openvas-devel mailing list
Openvas-devel@wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
