However, the gvmlibs in the container are:
root@fd2442c41277:/# find /usr/ /lib -name “libgvm*” -type f
/usr/local/lib/libgvm-pg-server.so.21.4.4
/usr/local/lib/libgvm_gmp.so.21.4.3
/usr/local/lib/libgvm_base.so.21.4.3
/usr/local/lib/libgvm_boreas.so.21.4.3
/usr/local/lib/libgvm_util.so.21.4.3
/usr/local/lib/libgvm_osp.so.21.4.3
The openvas-scanner is currently a version behind in the container because it segfaults, but the report is for gvmlibs which is at 21.4.3.
Is this reporting because of the openvas-scanner, or is there a problem with the NVT ?
The VT in question is using the OPENVAS_VERSION constant which was placed in the gvm-libs/openvas-libraries source code a wile ago but was moved to the openvas-scanner in newer GVM versions and is now returning the version of the openvas-scanner and not the one of gvm-libs.
Unfortunately the text was missed to be updated in the past, i’m currently in the progress to update the related text part to reflect the above.
One the openvas-scanner scanner package was updated to 21.4.3 the message will be gone.
Please do note that such an update to the version 21.4.3 of openvas-scanner is strongly recommended as it is including quite some important bug fixes for e.g. interrupted scans and also introduces new scanner capabilities for VTs which would lead to e.g. lower scan coverage (e.g. false negative risk for vulnerabilities) and similar:
The lower scan coverage is also the main reason for the existence of this VT to make users aware that outdated versions are used until a better way exists to make users aware of this (e.g. an update notification within GVM).
@cfi
Thank you. That’s what I expected. I had hit a wall on trying to find why the scanner was segfaulting … I suspected there was a problem with directory structure or permissions in the container, so I’ve been going round and round trying to make sure everything in the container file system was as it should be. ( Breaking/fixing things along the way.) This morning, I successfully built the container with 21.4.3 and no segfault, so it would seem the pain of rebuilding the filesystem in the container has paid off.
