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

[Jan-Oliver Wagner]

On Friday 25 May 2007 08:07, oday at fas.harvard.edu wrote:
> 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.

I think it is desireable to have a database used for OpenVAS.
However, above you proposed to used virtually for every task :-)

To keep the task simple, I'd propose to stick first to the OpenVAS Server
and there to storing results. Once this works reliable, we could move on
and design more functionalities based on a database.

Oliver: I'd welcome if you could prepare patches against OpenVAS Server
introducing the database. Currently I am lacking the time to try
it myself. Would you take over the topic "database"?
  
> 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.

sqlite is cool. We used it in several projects. It's good to avoid
obligation of database administration. SQL interface could be user
later on for any other database.

Again, in a first instance I would  avoid putting the NASLs into the database,
because it makes changes complex.
Also not the knowledge base because I expect performance impact
which I assume to be negative (without having tested anything here).

I do not dislike XML, but IMHO the rationale to introduce it must be good.
One standard advantage of XML is solving the encoding problem but currently
this appears not to be a problem with Nessus/OpenVAS.

Best

	Jan

-- 
Dr. Jan-Oliver Wagner                        Intevation GmbH, Osnabrück
Amtsgericht Osnabrück, HR B 18998             http://www.intevation.de/
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner