English |
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 #21: OpenVAS-Client: Improve Vulnerability Summary Listing
- 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 #30: OpenVAS Administration Protocol (OAP)
- 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
- CR #48: Define OMP in RelaxNG Schema Language
- CR #49: Introduce new phase for network scans
- CR #52: Tighter integration of nmap
- CR #53: Remove Support for Shared Sockets
- CR #55: Decentralized CPE identification
- CR #56: NVT Feed Meta Data Improvements
Change Requests: Accepted and in progress
- CR #24: OpenVAS-Server: Reorganize NVTs in Subdirectories
- CR #29: OpenVAS Unified Logging
- CR #54: Improve SSH Support
- CR #57: NVT Feed Product Detection Improvements
- CR #58: NVT Feed CVSS consolidation
Change Requests: In Discussion
- CR #26: OpenVAS-libnasl: Introduction of more phases in NASL
- CR #43: NMAP based service detection
- CR #50: Automatic restart of openvas-scanner after plugin updates
- CR #51: Add HTTP/HTTPS proxy support to openvas-libraries
- CR #59: NVT Feed message consolidation
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.
