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

Status: Voted +2. In progress; command line parsing in openvas-server and openvas-libnasl has already been migrated to glib starting with 2.0-beta1.

Purpose

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.

References

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

Rationale

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.

Effects

• OpenVAS Server would require glib to run.
• The more functionality is moved over to glib the more complicated it will be to migrate to other APIs as glib does not implement any standard. In the case it should eventually be decided to not link against the upstream glib anymore (e.g. it gets abandoned or badly maintained), then it would be necessary to maintain a copy of glib with only the relevant features inside OpenVAS. At least until it might be decided to migrate to other API(s).

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.

• Adapt the configure and make process for openvas-libnasl and openvas-server to consider glib.
• Migrate the command line parsing from getopt to glib. See glib API for command line parsing.
• Remove any occurrence and handling of the getopt copies.
• Evaluate whether the random number API of glib should replace the module "rand" in openvas-libraries and other uses of random numbers.
• Evaluate where the lexical scanner of glib could replace code. Not meant is the NASL interpreter here but several parsing tasks of the protocol and complex parameters.
• Evaluate which of the GLib Data Types to be used to replacing arglist and other data management.

History

• 2008-10-21 Michael Wiegand <michael.wiegand@intevation.de>:
  Updated status.
• 2008-06-18 Jan-Oliver Wagner <jan-oliver.wagner@intevation.de>:
  Added voting result.
• 2008-06-10 Michael Wiegand <michael.wiegand@intevation.de>:
  Moved parts relating to OpenVAS-Client to Change request #11.
• 2008-05-05 Jan-Oliver Wagner <jan-oliver.wagner@intevation.de>:
  Initial text.