English | Deutsch
Home »

OpenVAS Change Request #9: Make OpenVAS use (and depend on) glib

Status: Voted +2. Done. Increasing use of glib and dependency since release of 2.0 series.


To reduce code base of OpenVAS by using storage, command line parsing and several other functionalities of glib instead and thus share the effort to maintain and optimize base functionalities among a broader developer/user base.


Initial discussion on openvas-discuss mailing list where this request emerged from.


OpenVAS includes several code elements that are either copies from third parties (e.g. getopt) or self-implemented solutions that re-implement already available solutions (e.g. arglist concept). Probably both was done with portability in mind. The latter perhaps aimed at having performance screws better under control. However, these decisions were done many years ago in the Nessus times.

As for the portability issues, it is indeed a problem that libc implementations do differ in details and would cause alternative code paths in OpenVAS. A advantage of glib is that there exists only a single implementation that aims to run on many different platforms, even including Windows. Thus, using the glib API will not lead to alternative code paths to maintain several platforms.

It is usually not recommended to link large libraries into a security relevant program, because security problems of the library might be inherited as well. However, a broadly used library with many users, high expectations and an active developer community might offer better quality than a re-invented code under own control but which receives only little review. It is out of scope for OpenVAS to develop criteria that enable to balance out advantages and disadvantages of this design decision in general.

The main issue to solve with glib is to use its functionality to replace all "arglist" based storage handling of OpenVAS in order to gain a better performance and less OpenVAS source code. Other gains could be to replace any "getopt" by the respective API of glib for command line parsing and other functionalities offered by the glib API.


Design and Implementation

This is not worked out in great detail yet, as it is partly still to be evaluated which elements of glib are to be used in which way.

Basically, the idea is to have a initial step that creates the dependency to glib and delivers a first helpful feature easy to implement. Command line parsing appears to be this feature.