[Openvas-discuss] Ideas and wishes for future improvements ofOpenVAS

[oday@fas.harvard.edu]

Quoting Jan-Oliver Wagner <jan-oliver.wagner at intevation.de>:

> I also though about condensing e.g. all the debian local security checks
> into few files (maybe for each year). I am not sure, but this might speed up
> checks as well.
> But on the other hand this means to have one plugins that tests for
> x hundred CVEs. Would this cause trouble in some form?
> Which way is the best from the very practical side?

If we decide to move forward with the database model (which I'm very much in
favor of) then the code will expect to read and write results, nasls, etc from
a database structure.  But we shouldn't make a database a requirement to using
the application which means having a flat file option.  It would be easier, I
think, to have the flat file database represented as an XML file which would
act as a database.  I am assuming of course that the db library would have a
XML adapter which would make the coding efforts easy.  This would also give us
some flexibility to experiment with newer delivery models for the NASL file
such as an RSS feed.

That being said a friend just pointed out that sqlite3 would also be a suitable
flat file database which we could distribute.  The NASLs could be stored in
there as well as results from scans (e.g. a knowledgebase).  I'm ok with either
 idea but I realize some people really don't like XML.

Oliver