Goodbye OTP

It is time to say goodbye to the ancient OpenVAS Transfer Protocol (OTP). This is the communication protocol gvmd and openvassd use for communication. It was declared an internal API many years ago, so the removal will not affect any other client tool than gvmd.

We inherited this protocol from the pre-openvas times. Several drawbacks in the design such as the encoding problem and the stateful permanent connection were obvious, but we solved other challenges first and encapsulated the protocol for the time being. The new protocol OSP (Open Scanner Protocol) avoids the drawbacks and meanwhile grew mature to cover even the complexity of OpenVAS Scanner.

In the upcoming weeks and months we will remove OTP from master branch of the code. It becomes mandatory to use a OSP wrapper for OpenVAS-Scanner, which we concurrently develop: ospd-openvas.
A subsequent change is that openvassd turns into just openvas. In other words it is not working as a daemon anymore, and rather becomes a command line tool, issued on purpose by ospd-openvas.

All this impacts only those people who use the master source branch directly. Other users will not observe a change in behavior, even in GOS-6 or GVM-11 where the change finally gets into effect.

Although the change is neither visible in the GUI nor measurable in terms of performance, it yet reveals a strong advantage for our users and customers: Code quality. An architecture of task-oriented components makes it easier to gain high quality for each component. The components are simpler and thus less error-prone and they get easier to understand. The task of the scanner component is simply … to scan! Handling multiple concurrent clients with a dedicated protocol language is the task of a service management component, not the task of a scanner component. A fantastic additional benefit is that we can re-use the same base of the service component to control other scanners.


Is OSP intended for scanner for NVTs or also for VTs – and even other stuff?

E.g. can I use it to use (and/or deploy) a custom scanner for, say, the list of installed dpgk packages and their version numbers, the hashes of all files on the machine (“tripwire”), users/groups/SEL settings, etc.?

Or is there a better way to do this, or even an existing tool I’m missing?

OSP is designed to wrap arbitrary scanners or to embed new own ones in order to let them be controlled by a central orchestration unit. With GOS 6 / GSM 11 we established the substantial step to cover all of the complexity of OpenVAS with OSP and also to connect it to gvmd.

We are working next on the orchestration which surely will also include a dpkg and other such scanners.
The developers at Greenbone have some pretty ambitious goals for a distributed orchestrated scanning framework.

So yes, OSP is the right answer to your ideas. Full orchestration capabilities for it are on their way but no target date available yet.