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 structured progress of the OpenVAS products to external people.
Change Request status can be: in discussion, accepted, rejected, in progress, done.
Change Requests: Done
- CR #1: Introduce OID as replacement for script_id
- CR #2: Remove any support for NSR export format of OpenVAS-Client
- CR #3: Remove plugin factory from openvas-plugins
- CR #4: Remove plugin upload feature
- CR #5: Remove BPF sharing feature
- CR #6: Remove support of old XML report format
- CR #7: Extend report widget with optional info on NVT name/oid in OpenVAS-Client
- CR #8: Introduce NVT family "Credentials"
- CR #9: Make OpenVAS use (and depend on) glib
- CR #10: Remove support for non-SSL connections in OpenVAS-Client
- CR #11: Make OpenVAS-Client use (and depend on) glib
- CR #12: Replace NTP with OTP
- CR #13: Integrating the OVAL interpreter ovaldi into OpenVAS Server
- CR #14: OpenVAS-Client: Remove source code copy of gdchart and gd
- CR #15: OpenVAS Server: Remove features for detached scans
- CR #16: OpenVAS-Client: Do not automatically enable new NVTs
- CR #17: OTP: Make NVT signatures available to OpenVAS-Client
- CR #18: OpenVAS-Client: Improve Handling of False-Positives
- CR #19: Agree on a style guideline and on a format for the documentation
- CR #20: OpenVAS: Improve SSH Credentials Management
- CR #22: OpenVAS-libnasl: Introduce new script_tag Command
- CR #23: OpenVAS-libnasl: Standardize Script Families for NVT
- CR #25: OpenVAS-libnasl: Introducing support for WMI
- CR #27: IPv6 support
- CR #28: OpenVAS Management Protocol (OMP)
- CR #31: OpenVAS-Server: Remove support for plaintext password storage
- CR #32: Discontinuing the tarball releases of openvas-plugins
- CR #33: Change server-side NVT cache from binary dumps to keyfiles
- CR #34: Upgrade OpenVAS Server dependency from glib 2.6 to glib 2.8
- CR #35: OpenVAS-Client: Migrate from OpenSSL to GNU/TLS
- CR #36: NASL: Remove current i18n concept
- CR #37: Make openvas-client depend on openvas-libraries
- CR #38: Reorganize OpenVAS libraries
- CR #39: Mandatory KB keys
- CR #40: find_service.c and NMAP service detection
- CR #41: Adoption of CVSS Standard
- CR #42: Adoption of Risk Factor standard for NVT's
- CR #44: Integrating NMAP NSE's into OpenVAS
- CR #45: OpenVAS-Scanner: add pausing of scans
- CR #46: Remove Session Saving feature from OpenVAS Scanner
- CR #47: OpenVAS-Scanner: Keep uploaded files in memory instead of on disk
Change Requests: Accepted and in progress
- CR #24: OpenVAS-Server: Reorganize NVTs in Subdirectories
- CR #29: OpenVAS Unified Logging
- CR #48: Define OMP in RelaxNG Schema Language
Change Requests: In Discussion
- CR #21: OpenVAS-Client: Improve Vulnerability Summary Listing
- CR #26: OpenVAS-libnasl: Introduction of more phases in NASL
- CR #30: OpenVAS Administration Protocol (OAP)
- CR #43: NMAP based service detection
- CR #49: Introduce new NVT category ACT_NETWORK
- CR #50: Automatic restart of openvas-scanner after plugin updates
Change Requests: Rejected
- none yet
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.
Ideas for future OpenVAS functionalities
These ideas result from general brain storming on the openvas-discuss mailing list and OpenVAS developer conferences and have not yet lead to a change request. If you would like to see a particular idea implemented or would like to implement it yourself, please feel free to formulate a change request as described above.
- Direct support of Database:
OpenVAS Server should optionally write results into a database. It is to be discussed whether this is done additional to sending the results via Nessus Protocol. Also the question is open whether the server manages access to the database directly or whether users submit DB connection and authorization details so that the data are written there.
- Trace function:
Show sets of queries. Each query is composed of the rule that was used, the destination IP and port, the data sent, and the data returned. This will make it easier to determine false positives.
- Condensed Plugins:
E.g. all the Debian local security checks could be condensed into few (for each year). It is not clear yet which other implications this might mean.
- Generic Plugins:
Plugins with some heuristics to generically detect weaknesses in web applications.
- Consider popular issue-tracker or helpdesk systems to pull issues from scan reports, sort them, prioritize and assign them.