OpenVAS Change Request #32: Discontinuing the tarball releases of openvas-plugins
Status: Voted +10. Done. No openvas-plugins release with openvas 3.0.0.
To minimize potential conflicts in the server cache.
To create additional methods for feed synchronization.
To reduce the complexity of installing OpenVAS.
Currently the OpenVAS test routines ("NVTs", "plugins") are pubslished in two ways:
- Through releases of the openvas-plugins module as a tarball, without signatures.
- Through security feeds like the OpenVAS NVT Feed, with signatures.
Due to certain effects of the feed synchronization script, a race condition in the server cache is possible if the cache has been generated after a tarball installation (or a package installation on a distribution) has taken place, but before the local plugin collection has been synced with a security feed. The result of this race condition is that the server will use outdated cached versions of plugins that have changed in the feed instead of the updated version.
A workaround for the synchronization script has been tried, but resulted in disproportionately increasing the time and bandwidth needed to synchronize with the feed.
Furthermore, the current synchronization script relies exclusively on rsync being available and being able to connect to the feed server. Especially in restricted environments, this may not always be the case.
Since the openvas-plugins tarball release does have potential negative side effects and is of limited usefulness on its own (all users will probably use a synchronization script anyway after installation), this Change Request proposes the discontinuation of releases of the openvas-plugins tarball. The parts of the openvas-plugins tarball which are not present in the feed (namely, the C based plugins and the synchronization script) will be moved to the openvas-server package.
To enable feed synchronization even in restrictive environments, the synchronization script should be able to fall back to alternative synchronization methods in case synchronization with rsync is not possible. For this to be possible, the feed contents have to be made available through other protocols (e.g. HTTP, FTP) as well.
An option to provide feed services with encryption can be offered. Encryption addresses the need to keep any potential future sensitive data private (e.g. secure logins to feed servers) and also as a "best practices" implementation. Encryption, even in the absence of sensitive data will raise the confidence level of potential deployment sites. Such practices are also a component of "defense in depth" which is designed to raise the level of effort needed by an intruder to such a level that network penetration becomes uneconomical.
The openvas-plugins module will no longer be released.
After a server installation, it will be necessary to do an intial synchronization with a feed before the server is started for the first time. Otherwise, the server will only display no or very few NVTs.
The feed synchronization script will become more robust and will be able to synchronize with the feed even in restrictive networks.
Design and Implementation
There will be final openvas-plugins release. A test will be added to the configure environment to make sure it will not install in case openvas-server >= 2.1.0 is installed, and notify the user that from openvas-server >= 2.1.0 on openvas-plugins is not needed anymore.
The synchronization script and the remaining C-plugins will be moved to openvas-server.
After installation of openvas-server, the user will be notified that he or she has to synchronize with a feed service to make openvas-server operational.
The openvas-server version will be increased to 2.1.0 to indicate the change. openvas-server will conflict with any installed openvas-plugins module.
The feed update mechanism will be changed to make the feed available through transfer methods beyond rsync as well.
The synchronization script will be modified to fall back on alternative methods in case the synchronization is not possible via rsync.
- 2010-01-06 Felix Wolfsteller <firstname.lastname@example.org>:
Updated status as done.
- 2009-05-20 Michael Wiegand <email@example.com>:
Updated status with voting results.
- 2009-05-19 Geoff Galitz <firstname.lastname@example.org>:
Added paragraph suggesting encryption options to "Suggested Changes."
- 2009-05-13 Michael Wiegand <email@example.com>: