OpenVAS Change Requests

OpenVAS Change Requests describe proposed changes to one of the OpenVAS components. Though this is a formalized approach, this does not replace open discussion among interested developers on the mailing lists. From such open discussions, CRs emerge as a summary sooner or later. This transparently demonstrates the structure progress of the OpenVAS products to external people.

Overview on change requests so far

(Status can be: in discussion, accepted, in progress, done)

• OpenVAS Change Request #1: Introduce OID as replacement for script_id (in progress)
• OpenVAS Change Request #2: Remove any support for NSR export format of OpenVAS-Client (done)
• OpenVAS Change Request #3: Remove plugin factory from openvas-plugins (done)
• OpenVAS Change Request #4: Remove plugin upload feature (in progress)
• OpenVAS Change Request #5: Remove BPF sharing feature (done)
• OpenVAS Change Request #6: Remove support of old XML report format (done)
• OpenVAS Change Request #7: Extend report widget with optional info on NVT name/oid in OpenVAS-Client (done)
• OpenVAS Change Request #8: Introduce NVT family "Credentials" (done)
• OpenVAS Change Request #9: Make OpenVAS use (and depend on) glib (accepted)
• OpenVAS Change Request #10: Remove support for non-SSL connections in OpenVAS-Client (done)
• OpenVAS Change Request #11: Make OpenVAS-Client use (and depend on) glib (done)
• OpenVAS Change Request #12: Replace NTP with OTP (in progress)
• OpenVAS Change Request #13: Integrating the OVAL interpreter ovaldi into OpenVAS Server (in progress)
• OpenVAS Change Request #14: OpenVAS-Client: Remove source code copy of gdchart and gd (done)
• OpenVAS Change Request #15: OpenVAS Server: Remove features for detached scans (in progress)
• OpenVAS Change Request #16: OpenVAS-Client: Do not automatically enable new NVTs (in discussion)

How to write a change request

There are several sections for a change request for the various aspects of the proposed change. A change request can be iterated, so it is not mandatory to fill in e.g. a highly detailed implementation plan in the first version. Just try to give as much information as you feel helpful and able to provide. Read the existing change requests as examples.

• Status: General description of the status. Could be something like "in discussion", "agreed (voted +3) for release 1.4" or "Step 1 and 2 implemented".
• Purpose: What should be achieved in a few words.
• References: Links to corresponding issue tracker entries or mailing list discussions.
• Rationale: Why is it needed.
• Effects: How is API, compatibility, user experience etc. influenced?
• Design and Implementation: Any technical details that seem appropriate.
• History: Date, name and description of changes in ChangeLog format.